オープンソースカンファレンス 2019 Osaka

1 月 26 日に開催されたオープンソースカンファレンス 2019 Osaka に参加しました。

会場は大阪市にある大阪産業創造館 3F / 4F でした。3F はセミナーや企業系ブースが、4F はコミュニティ系ブースが並んでいました。

今回はセミナーを行わなかったので、ブースで openSUSE の紹介を行いました。
KOF 2018 から新たに関西在住となった中ギーコくんとちびギーコくんがブースを飾りました。

ブースでは openSUSE の紹介のような一般的な話から Transactional Update の話といったコアな話まで、多くの方とお話をすることができました。
元がビジネス向けだったためか、パーソナルな用途よりもビジネス向けの話(コンテナとか YaST での設定の容易さとか)に興味を持たれる方が多かったように思います。

openSUSE の紹介をするとよく聞かれるのが「openSUSE の特徴って何ですか?」という質問です。
この質問に対して、私は「YaST という設定ツールで GUI / CUI(ncurses) どちらからでも同じように設定が行えることです」と答えています。実際、家で使っているデスクトップでは設定ファイルを編集する機会がかなり減っているように感じています。

 

OSS 系コミュニティ合同 LT 大会 in 関西

翌 27 日は関西 Debian 勉強会、LILO、東海道らぐさんと合同の LT 大会に参加しました。

私は openSUSE の紹介と、KOF の東海道らぐ LT で発表した「SKK のススメ」を編集して発表しました。


SKK の利用による小指の酷使については、いくつか改善方法を教えていただいて、現在検討&お試し中です。

 

今後の予定

今後は、8 月 2 日(金)・3日(土)に開催するオープンソースカンファレンス 2019 Kyoto にブース出展する予定です(セミナーは未定)。
OSC 2019 Kyoto は会場となる京都リサーチパークが開催する KRP Week のひとつとして開催されます。
KRP Week では他にも様々なイベントが開催されるので、ぜひお越しください。

その前に、Leap 15.1 のリリースパーティ@京都サテライトを5月ごろに開催するかも知れません。
開催する場合は connpass にてイベント登録しますので、ぜひご参加ください。

橋本修太です

さて、突然ですが、今私の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年のふり返りと来年に向けてを書きます。

この記事は openSUSE Advent Calendar の 20日目です。完走も見えてきました。

さて、今日は Twitter などでときどき質問が飛ぶ Google Chrome のインストール方法です。

openSUSE では Google Chrome の OSS 版である Chromium がパッケージとして提供されています。普通のウェブサイトを見る分にはこれでよいのですが、Flash Player が必須なウェブサイトや、DRM で保護された不自由なコンテンツを見るために、ときどき Chrome が欲しくなるときがあります。

それでは、インストール方法です。

(1) Google のリポジトリのGPG 公開鍵のインポート

Chrome のパッケージを署名している鍵の公開鍵をインポートします。この手順を飛ばすとパッケージの署名チェックでエラーになってしまいます。

こちらのページにも手順が書かれています:
https://www.google.com/linuxrepositories/

(2) Chrome をダウンロードする

ブラウザで Linux 用の Chrome のrpmファイル(Fedora/openSUSE用)をダウンロードします。

https://www.google.com/chrome/

※Windows などからダウンロードする場合は、画面の下部に「他のプラットフォーム」というリンクから Linux 版のダウンロード画面にたどり着けます。

(3) セットアップを実行する

ダウンロードした rpmファイルを zypper でインストールします。

おわりに

以上、Chrome のインストール方法でした。Amazon Prime などの動画配信サイトが見られないといったような場合は、Chrome を試してみて下さい。

明日は「openSUSEでディスクの健康状態を取得」です。

この記事は、「openSUSE AdventCalendar 2018」19日目の記事です。

皆さんこんばんわ。橋本修太です。

今日は、本家MLでみかけた豆知識について紹介したいと思います。

スレッドの流れ

①投稿者は、古いラップトップがTumbleweedで上手く動かないようです。でも、Windowsや、Leapだと上手く動く模様。そして、エラーメッセージを添付しています。

②エラーメッセージを見た他の方が、対処方の書かれたページを案内してくれます。「グーグルすれば見つかるよ」

③投稿者は、そこにかかれてあった方法で無事に解決しました。「なんてことだ、どうしてぐーぐる事をすぐ忘れてしまうんだ」(すみません、多分な訳です)

めでたしめでたし・・・・なのですが、この次に、SUSEで カーネル開発を行っている岩井氏が、次の投稿を。

④【意訳・一部抽出】ちょっとこのバグについて補足を。どうしてこの現象がLeapでは起こらないかと言うと、Leapのカーネルにはワークアラウンドを適用していて、この手のバグが発生しないようにしている。それに対して、Tumbleweedは可能な限りupstreamに近い形を保持しようとしているので、こういうワークアラウンドは適用していない。そのうちupstreamで修正されるんじゃないか?

※①のMLはこちら 右下のnextから次の投稿へ進めます。

ふむふむ。確かに、TumbleweedとLeapのコンセプトに合うやり方ですね。

カーネル

そこで、カーネルのパッケージを眺めてみたのですが・・・申し訳ありません!リテラシーが無さ過ぎて、ここだ、という部分は見つけられませんでした。

眺めてみたページはこちら。

kernel-source.changesを比べてみるのが、それっぽかったです。Tumbleweedは次々と新しいバージョンのカーネルが適用されるログが見られ、Leapは長いことパッチ適用が続いています。(少なくとも、そういうふうに見えました。)

TumbleweedはTumbleweedで、パッチ類は何もしていない、という訳でもなさそうですね。

課題&感想

  • カーネル読みたい
  • そもそもOBSでのパッケージングを知りたい
  • 機会があれば岩井さんとお会いしたい
  • Tumbleweedの方にだけ、klpなんとかっていうのがあって、どうも、Kernel Live Patchの事っぽい

明日は @ftake さんによる、openSUSEでChromeを使う方法です。こちらもemacsインストールの記事等のように、即効性の高い記事になりそうですね。こうご期待。