橋本修太です

私が、では無く、ユーザ会で、なのですが、「日経Linux 9月号」に「openSUSE Leap 15.1がリリース 会議では今後の方針も明らかに」と題してレポートを書かせて頂きました。(文責は私でございます。)

内容は、「GeekoMagaze 2019 夏」号で武山さんが記事にされているLeap15.1の紹介から要点と、5月にニュルンベルグで開催されたopenSUSE Conference 2019のレポートです。

Leap 15.1は、マイナーバージョンアップリリースなので目玉機能とかよりは15.0からのスムーズな移行に重点が置かれているのですが、それでも細かい所は結構かわっていて(YaSTやカーネルへのパッチなど)、openSUSEユーザはもちろん、ユーザで無くとも興味を持って頂ける記事となっています。

是非、この記事で状況を把握していただいて、openSUSE Leap 15.1 を使ってみましょう

日経Linux 9月号 オフィシャルはこちら

Geeko Magazine 2019 夏

By ftake @ 2019-07-30 23:56

この夏もGeeko Magazine を発行します。2014年冬から始まった Geeko Magazine Special Edition はついに10巻目となりました。

最初の頒布は8月12日(月)コミックマーケットC96 南 ラ-03a です。今回から入場時にカタログに付属のリストバンドが必要になりますのでご注意下さい。コミケの後は技術書典や OSC 東京で頒布予定です。

今回の内容はこんな感じです。ちょっと難しめかもしれません。

  • openSUSE Leap 15.1 リリース!
  • 仮想マシンは遅いのか?仮想マシンと物理マシンのディスク I/O 速度比較
  • Docker Compose とは何が違う?Rails アプリを Kubernetes にデプロイしてみた
  • Docker・Kubernetes の永続化ボリューム攻略
  • eBPF を用いた PostgreSQL のクエリショル時間の計測
  • 鏡の向こう第5話: 放課後
    openSUSE Leap + CUDA で TensorFlow を動かすよ~!

それでは、日本 openSUSE ユーザ会のスペースでお待ちしております。

openSUSE mini Summit 2019 を開催

By ftake @ 2019-07-29 00:36

年に1回の openSUSE ユーザーが集まるイベント、 openSUSE mini Summit を 7月20日に開催しました。近年は Open Source Summit Japan の翌日に開催しています。今回の参加者は26名でした。

今回の会場はサイバートラスト株式会社の会議室を使わせて頂きました。ありがとうございました。

受付は特大ギーコとTuxが並びました。

オープニング

オープニングでは、昨年の mini Summit から今日までの活動を振り返りました。参加した OSC などのイベントと開催したイベントは17回ありました。また昨年末には Advent Calendar に参加し、7人で25日分のブログ投稿を行って完走することができました。

次にアイスブレイクで、参加者全員に自己紹介をしてもらいました。 1人持ち時間30秒で 、読んで欲しいお名前と、興味のあること、お仕事、関係するコミュニティなどを話してもらいました。

アイスブレイクの様子

openSUSE Leap 15.1 リリース!

発表者: ftake

15.1 のカーネル、Snapper の容量表示、YaST の改良点を中心に説明しました。会場には Debian や Ubuntu のコミュニティからも参加者がいたため、SLE とパッケージはバイナリレベルで同一なのか?といった質問が出ました。(ソースレベルで同一で、バイナリは異なる)

openSUSE Conference 参加報告

発表者: ftake, hashimotosyuta, masayukig

openSUSE Conference の参加者が前に出て、写真を見ながら当日の様子を紹介しました。ソーセージとビールの写真が多めだったかもしれません。

openSUSE with OpenSDS

発表者: hashimotosyuta

様々なストレージエンジンをコントロールして、ストレージを作成できる OpenSDS を openSUSE で使う話です。残念ながら今のところ openSUSE 向けのパッケージは用意されていないようです。

Kubernetes the hard way on openSUSE OpenStack cloud

発表者: masayukig

GCP に手作業で Kubernetes をインストールする Kubernetes the hard way の紹介、新しいお家 Open Stack クラスタの紹介と、この Open Stack 上に Kubernetes クラスタを構築する話でした。
資料: https://github.com/masayukig/k8s-the-hard-way

openQAを使ってテストケースを作成してみる

発表者: nagayasu

openQA は openSUSE の自動テストで使用されている GUI テストツールです。openQA をローカル PC にインストールし、Live 起動のディストリビューションのテストのデモが行われました。

openQA について

ショートトーク

emaxer さんと鹿さんによる飛び入り発表。XDP のパケット処理の話は OSC 京都で聞けます。

XDPによる高速パケット処理のショートトーク

じゃんけん大会・クロージング

中サイズのカメレオンのぬいぐるみや、Tシャツなどがもらえるじゃんけん大会を行いました。プレゼントの数は十分にあったため、みなさん何かしら持って帰れたのではないかと思います。

じゃんけん大会
集合写真

リリースパーティ

すぐ隣のラウンジに移動し、少し遅めの Leap 15.1 のリリースパーティを開催しました。スパークリングワインで乾杯!

今回は初めての方も多くいました、じっくり交流して頂けたのではないかと思います。

橋本修太です

さて、突然ですが、今私のKubernetes環境はこんな感じになっています。

KVMは仮想マシン、KubicはopenSUSEのKubernetes専用ディストリビューション、masterやnodeはKubernetesクラスタでの役割を表しています。

ルーターに有線でデスクトップが繋がっていて、そこに3つKubicを走らせています。

また、ルーターはWiFiルーターに繋がっていて、WiFiでノートパソコンと通信、そのノートパソコンの上にも3つKubicが走っています。

それをですね、こうしたいのです。

デスクトップのnodeを、ノートパソコンのKubernetesクラスタに組み込みたいのです。

ノートパソコンは、メモリは16G積んでいて少し余裕はあるものの、CPUはcore i5で、KVMをこれ以上増やすのは難しいです。

そこで、クラスタの利点を活かして、デスクトップからnodeを引っ張ってくるわけです。

とりあえずこれでできました

KVMはデフォルトで閉じたネットワーク(ホストの外側からは中にアクセス出来ないネットワーク)を作成します。ただ、これはNATなので、ゲストからホストの外側にはアクセス出来ますが・・・

そこで、色々とやってみた結果、次のような方法でホストの外からのアクセスが出来ました。

  • 【ノートPC】KVMでバーチャルネットワークを作成、マスカレードで接続
  • 【デスクトップPC】ブリッジを作成

検証や調査等はおいおいやっていくとして、それぞれの設定を書いてみたいと思います。

今回は【ノートPC】編、次回は【デスクトップPC編】です

WiFi接続しているノートPCにブリッジを作成することに挫折

グーグル先生に教えてもらって、いくつかの方法を試したりしたのですが、どれも挫折してしまいました・・・

どうやら、ブリッジはレイヤー2で転送するものらしいのですが、WiFiはレイヤー2転送に対応していないというのが、WiFiでのブリッジ作成が難しい理由の大きなところらしいです。・・・いまいちピンとこないので、後ほど詳しく調べてみたいと思います。

parproutedやebtablesなどでレイヤー2転送を設定する

parproutedはarpをプロキシするものとの事です。また、etablesはEthernetフレーム用iptablesとの事です。parproutedはopenSUSE Leap15で上手く動かせられなかったり、ebtablesが意図した通り設定出来なかったりして、挫折してしまいました。

バーチャルネットワークを作成

Facebookでそんな事をなげいていたら、Saputro Aryuliant氏より、「KVMのバーチャルネットワーク設定して、iptablesでマスカレード設定すればいけるよ」とのお助けが。

「ホストPCの外から、ゲストPCにアクセスできる?」と聞くと、「iptables設定すればいけるよ」とのことでしたので、早速試してみることに。

KVMの設定

ルーティングでネットワークを作成します。

設定はvirt-managerでこんな感じです。

編集 > 接続の詳細

から、「仮想ネットワーク」タブを選んで、左下のプラスのアイコンをクリックして追加します。

デバイスにwlan0(WiFi)、方法にルーティングを指定している所がポイントです。

これ、デフォルトのNATネットワークだとだめなのかな?

iptablesの設定

まず、ノートPCでipv4のフォワードを有効にします。

sudo sysctl -w net.ipv4.ip_forward=1

これは再起動するとクリアされてしまいますので、常に設定したい場合は /etc/sysctl.d/の中に、{好きな名前}.confという名前で設定ファイルを作成して、その中に記述しておけばOKです。

確認は以下のコマンドで。

sudo sysctl -a

設定項目が表示されますので、grep -i forwardとかで絞ると楽に確認できます。

それから、同じくノートPCにマスカレードを設定します。

iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -j MASQUERADE

  • -t nat パケット中のIPアドレスを書き換える用のテーブルを編集
  • -A POSTROUTING 転送でパケットが出ていく時に処理を行う
  • -s ここで指定した所から来た(Source)パケットに対する処理
  • -j 指定した処理を行う 今回はマスカレード

これで、ノートPCの上で走らせているKVM上のKubicが、自由に外にアクセスできるようになりました。

ノートPCの上で走らせているKVMにデスクトップPCからアクセスする

とりあえず、アクセスしたいマシンやKVM上のKubicで、以下の設定を行いました。

ip -4 route add 192.168.100.0/24 via 192.168.0.12

192.168.100.0/24行きのパケットは、192.168.0.12(ノートPCのIPアドレス)をデフォルトゲートウェイにしてね、という設定です。

これで、デスクトップや、そこで走っているKVM上のKubicから、ノートPC上のKubicにアクセスできるようになりました。

・・・もちろん、デスクトップ上のKVMも、ブリッジ設定して、ホストの外へアクセスできるようにすれば、です。その様子はまた次回に。

感想&課題

  • ネットワークの基礎が無いのでちょっときつい
  • レイヤー2ルーティングでブリッジ作成は可能?
  • そもそもルーティングによる接続ってなんだろう
  • ホスト外からアクセスする方法がスマートでない
  • この辺りをもうちょっとまとめたい

橋本修太です。

例によって例のごとく、よくわからないけど動かなくなって、よくわからないままに手探りで解決したので、覚書を残させて頂きます。

現象

kubectlでdeploymentのyamlをapplyしても、DESIREDからCURRENTに移行しなくなった

要するに、新しいpod(Dockerで言うところのコンテナ)が動かなくなった、という事です。

原因

不明

直前に、nginx-ingress入れたりしていたんですけど、それでしょうか・・・・

解決方法

crictlで、Exitedなkube-controller-manager-****を削除したら、動き出しました。

手順

現象発生時、何かを調べたとは思うのですが、忘れてしまいました・・・とりあえずKubernetesを再起動させました。

NODEの削除(masterでの作業)

$ kubectl drain <node name> –delete-local-data –force –ignore-daemonsets
$ kubectl delete node <node name>

NODEの再起動(master含む各NODEでの作業)

$ kubeadm reset

$ reboot

いつもこの方法なんですけど、これでいいんでしょうか?

そして、いつもどおり起動していきます。

master起動

kubeadm init –cri-socket=/var/run/crio/crio.sock –pod-network-cidr=10.244.0.0/16

cp -i /etc/kubernetes/admin.conf ~/.kube/config

kubectl apply -f ./kube-flannel.yml

最後の、flannelのymlは、githubから落としてきたものです。詳細はGeeko Magazineをご覧ください。ただ、README.mdに書いてある、以下のコマンドでも正しく動きそうですね。flannelかな?と思って、こちらで試してみたのですが、動作は同じようでした。masterなので、いつどういう動作をするかは、保証されないのでしょうが・・・

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

そして、同じ現象に出くわします。nodeの状態を以下のコマンドで確認するのですが、

kubectl get nodes

ずっと、STATUSはNotReadyのまま。

kube-system(というnamespaceで配置される、システム系のpod)を確認します。

kubectl get pods –all-namespace

すると、kube-controller-manager-****(****は、マスターのマシン名)のSTATUSが、CreateContainerErrorとなったまま。

ふーむ・・・ここでグーグル先生に泣き付く事小一時間。こんな感じで辿りました。

ログ確認

journalctl

Kubicは、Kubernetes関係のログはほぼここに入っています。いるはずです。いると思っています。

すると、こんな感じのログが立て続けに出力されていました。

pod_workers.go:190] Error syncing pod
****************** (“kube-controller-manager-linux-riis_kube-system(*********************)”), skipping: failed to “StartContainer” for “kube-controller-manager” with CreateContainerError: “the
container name \”k8s_kube-controller-manager_kube-controller-manager-linux-riis_kube-system_********************_**\” is already in use by \”************************************
\”. You have to remove that container to be able to reuse that name.: that name is already in use”

******はマスクです。ランダム英数字が入っています。また、linux-riisが、masterのマシン名です。

podのログも確認してみましたが、同じようなログが出力されていました。(はずです・・・もしかしたら、コンテナを生成できなかった、程度だったかもしれません・・・)

kubectl logs pods/kube-controller-manager-****(マシン名) -n kube-system

-nオプションで、namespaceを指定しないと、見つからないと言われるので注意です。

ふむふむ、どうも、IDだかがかぶってしまって、新しいkube-controller-managerを起動できないようです。

ここでイメージとコンテナの確認です。Kubicはcri-oを使っているため、コンテナ関連のコマンドはcrictl、サービスはcrioになります。crictlのホームページはこちら。Dockerと似たような感じで使えるのではないでしょうか。ちなみに、このコマンドが入っているパッケージはcri-toolsです。

サービスステータスをチェックします。

systemctl status crio

CNIのデフォルトネットワークが見つからないよ、というエラーが見えますが、flannelを適応すれば直るでしょう・・・直ると信じたいです。(事実、直りました。)

では、コンテナの確認です。

crictl ps -a

すると、Runningとなっているものと、Exitedとなっているもの、2つのkube-controller-manager-****が。その他にも、kube-apiserver-****や、kube-scheduler-****も同じように、二種類。

Exitedとなっているものは不要なので(不要で終了したのでExitedなはずなので)、削除しましょう。

crictl rm ****(コンテナIDです。先のcrictl ps時に表示されます。)

そして、システム系のpodを確認。

kubectl get pods –all-namespaces

すると、なんと、kube-controller-manager-****が、Runningに変わっているではありませんか!

ただ、ちょっと待ってkubectl get nodesしても、NotReadyだったので、同じくExitedだった、kube-apiserver-****と、kube-scheduler-*****のコンテナも、削除しました。

そして待っていると・・・・無事、masterがReadyになりました。

後は、ワーカーNodeのkubeadm joinもすんなり動き、正常稼働に戻りました。

課題&感想

  • 情報収集の方法をもっと知りたい
  • crictl知ったのは良かった
  • Kubicの再インストールを考えたけど、粘ってみてよかった。(いつもこうとは限らない)
  • 正常時のログとかを認識していないと、異常時にあたりを付けにくい
  • ingressは、Kubic用があるっぽい
  • 今見てみたら、kube-schedulerとか、Exitedなのがあった・・・

openSUSE Advent Calendar 最終日です。おかげさまで、無事完走することができました。皆さん、クリスマスをいかがお過ごしでしょうか?

最終日は毎週日曜日の openSUSE 定例での振り返りと来年に向けてをお送りします。

まだイベントは30日のコミックマーケットが残っていますが、今年1年間ありがとうございました。来年は早々に京都で新年会がありますのでよろしくお願いします。

良いお年を。

openSUSE ユーザ会のブースの作り方

By ftake @ 2018-12-24 21:26

この記事は オープンソースカンファレンス Advent CalendaropenSUSE Advent Calendar の 24日目です。

この記事を読んで下さっている方は、オープンソースカンファレンス(OSC)で日本 openSUSE ユーザ会のブースを見たことがあるでしょうか?あの緑色の生き物(カメレオン)のぬいぐるみが積み上げられたブースです。最近はおとなしめですが、何年か前はおーぷんここんの狐のぬいぐるみや、オアシス君が結集して賑やかでした。

今日はこの openSUSE ブースを運営するノウハウを共有したいと思います。

ブースは立体的に盛る

OSC では、スペースは基本的には机1個と決まっていますので、ぱっと見たときに寂しいなと感じないようにするには、縦方向を上手く使うのが大切です。

openSUSEブースは下はテーブルクロス、上はミニのぼりを配置しています。特大ギーコぬいぐるみの下に青色の道具箱が毎回置いてあるのも、立体的に見せるためです。展示物の輸送にコストをあまりかけられないため使っていませんが、後ろにバナースタンドを置くのも良いかと思います。

デモ用のPCの高さを上げてあるのもポイントです。机の上の直置きだと、立ったまま見る・操作するには低すぎてしまいます。そこで100円ショップのプラケース2台を足にして、画面とキーボードの高さを上げています。

チラシ

openSUSEユーザ会ブースでの主な配布物は、チラシとステッカーです。OSC 東京では機関誌(同人誌)の販売もしています。

この中でも重要なのがチラシです。チラシは A4 カラー両面を2つ折にしたものです。受け取った後の仕舞いやすさ、印刷コスト(200枚で2000円以下、またはカラーレーザープリンタで印刷可能)、見た目のバランスを考えてこの形になりました。

チラシの内容(2, 3 ページ)は openSUSE のリリース情報や、セミナーの内容に合わせた技術的なことを入れるようにしています。内容は少なくとも年2回のOSC東京ごとに更新しており、毎回来ている方にも受け取ってもらえるようにしています。4 ページ目は openSUSE を知らない人向けの情報をまとめており、およその内容は10年ほど変わっていません。


声かけ

openSUSEブースでは、ここは一体何?という感じで近づいて下さった方に、まずはチラシを渡しつつ声かけをするようにしています。毎回 openSUSE をご存じですか?と最初は質問をするのですが、最近の OSC 東京では知らないという回答はかなり少なくなってきました。

ブースでの話が盛り上がることもよくあり。ブースでの一人あたりの平均滞在時間は長い方なのではないかと思います。ぜひ、お気軽にお立ち寄り下さい。

セミナー

ブースではありませんが、少しだけ。openSUSE のセミナーは、openSUSE の紹介(10分)+ アプリケーションなど、直接関係ない話と言う構成が多くなっています。と言いますのも、openSUSE のようなマイナーディストリビューション特化の話だと、ほとんど人が集まらないからです。そのため、アプリケーションよりのネタで人を集めつつ、プログラムのリンクをクリックしてもらえそうなキャッチーなタイトルになるように工夫しています。

例えば次のようなものがありました。

  • Ruby でできていると言っても過言ではない Linux ディストリビューション — openSUSE
  • トランザクショナルアップデート ― Btrfs を活用したパッケージ更新方法 / OpenStack アップストリーム開発者が語る、オープンソース開発の裏話
  • openSUSEで作る仮想化環境 ― KVM, Xen, Docker, etc. 仮想化技術の選択のポイント
  • Portus でプライベート Docker レジストリを作ってみよう
  • Solrで日本語全文検索システムの構築と応用~ドキュメント検索からオンラインショッピングサイトへの応用まで~
  • 今さら聞けない — Linux コマンドラインツールテクニック その1

今後、出展・発表をしてみたい方へ

OSC は新規出展の見た目上のしにくさが1つの大きな課題となっていると思います。しかしながら、実際にはそこまで大変ではありません。

1つの大きな難しさはコミュニティを立ち上げないといけないように見えることです。コミュニティを立ち上げるには、その OSS の誰かに許可を求めないといけないのではないか、複数人集めないといけないのではないのか、そもそもコミュニティを立ち上げられるほど、使って・貢献して・… ・いないなど、できない理由がいくらでも思いついてしまいます。

実際のところ、コミュニティ名義で出展する必要はなく、個人としてブースを出す、出展することも可能です。申し込み書がコミュニティとしての出展を前提とした内容になってしまっており、ここも抵抗感があると思いますが大丈夫です。

また、東海道らぐのようなごちゃまぜコミュニティに参加して、まずは東海道らぐの枠でライトニングトークをしてみるというのも良いのではないかと思います。

私個人としては、まだコミュニティ化されていない、時によってはマイナーな OSS のユーザーや開発者がOSCで発表して、そこから人が集まるようになったり、流行の OSS を使って○○してみたのような、経験を語るような発表がもっとあると、今後も OSC が盛り上がり続けることができるのではないかと考えています。

おわりに

なかなか書く機会のなかった openSUSE ユーザ会の出展ノウハウを書いてみました。OSC の特徴のコミュニティブースがよくなることが、来場者数が減少気味な OSC の盛り上げにつながるのではないかと期待しています。

明日は Advent Calendar 最終日です。オープンソースカンファレンスは久保田さんによる来年の OSC の計画の話です。openSUSE は明日も私で、昨日の定例での1年のふり返りと来年に向けてを書きます。