Geeko Magazine表紙のキャラクター壁紙

By Syuta Hashimoto @ 2019-08-04 14:12
  • 2019/08/04 画像サイズが小さかったのを、フルサイズに修正しました。
  • 携帯用をアップしました。
  • ※※画像はサムネイル表示になっています。フルサイズは「名前をつけてリンク先を保存」で保存してください。※※
  • ** IMPORTANT ** image is thumbnail. If you want to get this wall papers, you should download which linked to.

openSUSE mini Summit 2019でも、「欲しい!」とお声を頂いた、Geeko Magazine表紙に描かれたキャラクターの壁紙をアップします。

ぜひぜひ、ダウンロードしていただいて、デスクトップをかわいらしく飾ってください!

イラスト作成者からのコメント「携帯壁紙とか希望があれば、コメントいただければ作りますよー」

※2019/08/04 ご希望を頂いたので、携帯壁紙作成して頂きました。希望くださった方、イラスト作成者さん、ともにありがとうございます!

【デスクトップ用】

【携帯壁紙用】

橋本修太です

Geeko Magazineに書いていたのですが、ちょっと前、確かkubernetes 1.12の時は、flannel 1.10を適応しようとすると、エラーとなって適用出来ませんでした。

それが、flannelがバージョンアップして解決したようです。今では以下のコマンドでネットからflannelを適応する事が出来ます。

kubectl apply -f https://0y.at/kubicflannel

Kubicが適応できるバージョンにショートネームをあてたようですね。

インストールの全体記事はこちらです。

それでは良いコンテナライフを。

橋本修太です

さて、突然ですが、今私の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 の 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 Advent Calendar ももう17日目ですね

今日はこの blog が動いている geeko.jp のサーバーのメンテナンスの話です。このサーバーは ConoHa で動いており、13.1, 42.3 とアップデートをしてきました。今回は42.3 から 15.0 にアップデートしました。

アップデート方法

いつもオンラインでアップデートしています。クラウドの場合、ディスクイメージをダウンロードして、ConoHa にアップロードし、インストーラを起動してアップデートはちょっと大変です。オンラインアップデートであればリポジトリの URL を書き換えて zypper dup するだけなので簡単です。

リポジトリのURLを書き換える方法はいくつかありますが、YaST のリポジトリ設定からバージョンの部分を書き換えるのがオススメです。

ディスク容量には余裕があるので、一度ダウンロードが完了するのを待ってから、アップデートを適用しました。

MySQL から MariaDB へ

15.0 には、これまで提供されてきた mysql-community-server のパッケージがなく、完全に Maria DB に置き換えられています。やったことは以下の3つです。

  1. mariadb のパッケージをインストールする
  2. 設定ファイルを更新する
  3. systemctl で mariadb を自動起動するようにする

設定ファイルは、新しい設定ファイルをそのまま使いました。一応、これまでのファイルと新しい設定ファイル /etc/my.conf.rpmnew を比較したところ、内容はかなり増えていますが、コメントアウトされた部分以外はほとんど同じでした。

SuSE Firewall2 から Firewalld へ

Leap 15.0からCentOSなどでお馴染みの firewalld が使えるようになりました。これまでのSuSE Firewall2 も引き続き使うことができます。移行する場合は手動で SuSEfirewall2 パッケージを削除して、firewalld をインストールする必要があります。

Firewalld では次のように使用したいサービスのポートを開けられます。

Let’s Encrypt で TLS に対応

アップデートしたついでに、Webサーバーを TLS に対応させました。証明書は無償の Let’s Encrypt で取得しました。

Let’s Encrypt の certbot コマンドを使えば、証明書の取得から Apache の設定まで1コマンドです。このあたりの細かい話は Geeko Magazine SP 2018冬号に書いていますので、ぜひ読んでみて下さい。

変わらなかったもの: PHP とPerlアプリケーション

geeko.jp で動いていた WordPress や Vanilla Forum、Pukiwiki はそのまま動きました。このあたりは 13.1 からのアップデートと比べると、とても楽でした。

おわりに

ということで、大したことではありませんが、geeko.jp のサーバーをアップデートしたときの話を書いてみました。42.3のサポート期間はあと半年くらいですので、これから 15.0 にアップデートする方は参考にしてみて下さい。

明日は鹿さんが USB オーディオの話の続きを書いてくれるそうです。

 

 

 

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

皆さんおはようございます。橋本修太です。

さて、先日jaのMLにこんな投稿がありました。

【意訳】

openSUSE(Kubic)でCloud Foundry動かしたことある人います?

Kubicのキーワードが目に止まり、はて、Cloud Foundryとは?と思った私は、調査してみました。

本記事は情報収集のみとなります。「やってみた」は次の機会になりますこと、ご了承ください。

Cloud Foundryとは

ホームページはこちら。概要を纏めてくださっているページが幾つか有りますので、それらを見ていきますと、どうやら、webアプリケーションのソースコードをpushするだけで、ビルド・デプロイを自動で行ってくれる、オープンソースのソリューションの模様(商用版もあり)。イメージとしてはherokuに近いですね(こんな記事もありました)。

「アメリカのFortune 500企業のうち約半数が導入済み」といった謳い文句も見られますね。

インストール方法

いくつかあるようです。Cloud Foundry自体、複数のコンポーネントで構成されるソリューションなので、手順があったり、インストールを支援してくれるソリューションがあったりします。

また、Pivotal、SUSEなどがチューニングしたソリューションもあって、それぞれ強みがあるようです。

ちなみに、Cloud Foundryとやりとりを行うコマンドラインツール群、cf-cliは、openSUSEにパッケージがありました。(動くかな?)

A. PCF-DEVをインストール

PCFとは、Pivotal Cloud Foundryの略です。Pivotalはクラウドで有名な会社のようです。

ここが展開している、ローカル開発用のCloud Foundry、PCF-DEVが、インストールしてみるには丁度良いよ、という投稿もstack overflowで見たりしました。

構成としては、Linux(私の場合openSUSE)の上に、VirtualBoxを動かし、その中でPCFを動かすようです。

インストール方法はこちら

B. BOSHでインストール

BOSHは、Cloud Foundryの導入・運用を制御するソリューションのようです。

単一マシンに展開したり、クラスタ構成に展開したりもできるようです。

通常、Cloud Foundryをインストールと言えば、この方法が正攻法?なのかもしれません。

C. SUSE Cloud Foundryをインストール(on Vagrant)

SUSEも、Cloud Foundryには力を入れていて、チューニングしたソリューションを持っていました。

githubはこちら

主なチューニング点として、以下が挙げられていました。

  • Kubernetes(Docker)の上で動くように、Cloud Foundryのコンポーネントのコンテナライズにfissileを使っている
  • Cloud FoundryのコンポーネントはopenSUSE Steamcellで動く
  • オプションとして、Cloud FoundryのAppをopenSUSE stackのpreviewで動かす事が出来る

Steamcellだの、stackだの、previewだの、ちょっとピントこない単語が沢山・・・これらはおいおい調べていく事にしまして、1番目に付いて、もともとCloud FoundryはKubernetesの上で動くようには作られていなかったのですが、そこをSUSE等が開発したとの事です。

件のgithubには、on Kubernetesで動かす方法も記載されているのですが、ここではPCF-DEVと同じように、VMの上で動かす方法を。

Disclaimerに、「openSUSE 42.xは、libvirtでテストしてますよ」とあります。ここが42.xになっているのが、ちょっと気になるところですが・・・(あと、SUSEのgithubなのに、openSUSEがOpenSUSEになっている所とか)

あとは、Deploying SCF on Vagrantのセクション通りにやっていけばよさそうです。

ただ、要件にいきなり「メモリは16G以上は用意してね」とあって、私のデスクトップはもう無理状態です。

D. SUSE Cloud Foundryをインストール(on Kubernetes)

C.で触れましたが、Kubernetesの上にインストールできるのが、SCFの強みとの事。Helmでインストールするようですね。インストールページには要件等書いてありますので、適応させて行けば動くでしょうか?

ちなみに、環境チェック用スクリプトがあるのですが、Kubic上で走らせた所、半分ぐらいerrorとなってしまいました。

課題&感想

  • やってみる!
  • もう少し、正確かつ精密な情報を収集し、記事にする

駆け足で情報収集だけしたのですが、結構複雑な構成をしていて、ちゃんと理解しようとするとそれなりのボリュームになりそうです。使う側は、ソースコードをcf pushすれば、デプロイまで完了、とやりやすい事この上無いですね。

では、16Gメモリを積んでいるノートPCがあるので、近いうちにやってみたをやってみたいと思います。

明日は @ftake さんの、geeko.jpをメンテナンスした話ですね。塩漬けに近かったサイトですので、色々と面白い話題が出てきそうです。こうご期待。