最近、電源が壊れたPCを1台リプレースし、余ったマザーボード、CPU、メモリーでファイルサーバーを構築しました。その際にデータをファイルサーバーに移し、デスクトップ PC の HDD を外してしまったので、仮想マシン用の VM の仮想ディスクイメージもファイルサーバーに移す必要がありました。しかし、Hyper-V のディスクイメージは Samba サーバーに置くことができないようなので、仮想マシンのディスクイメージを iSCSI で Hyper-V に接続するようにしてみました。

今日は openSUSE Leap 15.2 (beta) で iSCSI Target（サーバー）のセットアップ方法を紹介します。今回設定する構成はディスクイメージを iSCSI で公開するファイルサーバーと、ファイルサーバーと同じネットワークにあり、そのディスクイメージを使用する Windows 10 のデスクトップ PC からなる単純なものです。

必要なパッケージは targetcli をインストールすれば揃います。YaST でも設定できるのですが、設定できる項目が少ないようなので、targetcli を使って設定します。

$ sudo zypper in targetcli

それでは targetcli を起動して設定していきます。

$ sudo targetcli

まずはディスクイメージファイルを作成します。targetcli の中で /backstores/fileio に移動して、create コマンドでディスクイメージを作成できますここでは /var/storage/disk1.img に 10 GB のディスクイメージ作成します。 /var/storage ディレクトリは先に作成しておく必要があります。

ls コマンドで disk1 が作成されたことが確認できます。

/> cd backstores/fileio 
/backstores/fileio> create file_or_dev=/var/storage/disk1.img name=disk1 size=10G
Created fileio disk1 with size 10737418240
/backstores/fileio> ls
o- fileio ............................................................. [Storage Objects: 1]
  o- disk1 ....................... [/var/storage/disk1.img (10.0GiB) write-back deactivated]
    o- alua ............................................................... [ALUA Groups: 1]
      o- default_tg_pt_gp ................................... [ALUA state: Active/optimized]

次に /iscsi で create コマンドを実行し、iSCSI の target を作成します。create の IQN 形式の ID を省略すると勝手に作成してくれます。

/backstores/fileio> cd /iscsi
/iscsi> create
Created target iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a.
Created TPG 1.
Global pref auto_add_default_portal=true
Created default portal listening on all IPs (0.0.0.0), port 3260.
/iscsi> ls
o- iscsi ...................................................................... [Targets: 1]
  o- iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a ................ [TPGs: 1]
    o- tpg1 ......................................................... [no-gen-acls, no-auth]
      o- acls .................................................................... [ACLs: 0]
      o- luns .................................................................... [LUNs: 0]
      o- portals .............................................................. [Portals: 1]
        o- 0.0.0.0:3260 ............................................................... [OK]

この target で公開するディスク (lun0) を作成し、最初に作成したディスクイメージ（/backstores/fileio/disk1）を割り当てます。

/iscsi> cd iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a/tpg1/luns
/iscsi/iqn.20...21a/tpg1/luns> create storage_object=/backstores/fileio/disk1 
Created LUN 0.
/iscsi/iqn.20...21a/tpg1/luns> ls
o- luns .......................................................................... [LUNs: 1]
  o- lun0 ....................... [fileio/disk1 (/var/storage/disk1.img) (default_tg_pt_gp)]

最後に、この taget にはデスクトップPC からしかアクセスできないようにします。ここではデスクトップPCのID（Windows の iSCSI イニシエーターに設定するもの）を iqn.2020-04.example.com:desktop-pc とします。tpg1/acls 内でイニシエーター名を指定し、create コマンドを実行します。さらに、ユーザーIDとパスワードを設定し、事実上誰からもアクセスできる状態にならないようにします。

/iscsi/iqn.20...21a/tpg1/luns> cd ../acls
/iscsi/iqn.20...21a/tpg1/acls> create iqn.2020-04.example.com:desktop-pc
Created Node ACL for iqn.2020-04.example.com:desktop-pc
Created mapped LUN 0.
/iscsi/iqn.20...21a/tpg1/acls> cd iqn.2020-04.example.com:desktop-pc/
/iscsi/iqn.20...om:desktop-pc> set auth userid=testuser
Parameter userid is now 'testuser'.
/iscsi/iqn.20...om:desktop-pc> set auth password=testpassword1234
Parameter password is now 'testpassword1234'.
/iscsi/iqn.20...om:desktop-pc> ls
o- iqn.2020-04.example.com:desktop-pc ..................................... [Mapped LUNs: 1]
  o- mapped_lun0 .................................................. [lun0 fileio/disk1 (rw)]

この段階で mapped_lun0 が作成され、iqn.2020-04.example.com:desktop-pc に mapped_lun0 が作成されます。Leap 15.1 で試したときは、この mapped_lun0 が自動的に作成されず、Windows の iSCSI イニシエーターから接続してもディスクが何も表示されない状態になってしまいました。このような場合は、次のコマンドで mapped_lun を作成することができます。

create mapped_lun=0 tpg_lun_or_backstore=lun0

これまでの設定は以下の通りです。この状態で Windows の iSCSI イニシエーターでファイルサーバーに接続すると、ディスクの管理で iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a の lun0 (/backstores/fileio/disk1, /var/storage/disk1.img) がディスクとして見えるようになります。あとは Hyper-V でこのディスクを割り当てれば仮想マシンのディスクとして使用することができます。

/> ls /
o- / ................................................................................. [...]
  o- backstores ...................................................................... [...]
  | o- block .......................................................... [Storage Objects: 0]
  | o- fileio ......................................................... [Storage Objects: 1]
  | | o- disk1 ..................... [/var/storage/disk1.img (10.0GiB) write-back activated]
  | |   o- alua ........................................................... [ALUA Groups: 1]
  | |     o- default_tg_pt_gp ............................... [ALUA state: Active/optimized]
  | o- pscsi .......................................................... [Storage Objects: 0]
  | o- ramdisk ........................................................ [Storage Objects: 0]
  | o- rbd ............................................................ [Storage Objects: 0]
  o- iscsi .................................................................... [Targets: 1]
  | o- iqn.2003-01.org.linux-iscsi.testserver.x8664:sn.b527a14e621a .............. [TPGs: 1]
  |   o- tpg1 ....................................................... [no-gen-acls, no-auth]
  |     o- acls .................................................................. [ACLs: 1]
  |     | o- iqn.2020-04.example.com:desktop-pc ........................... [Mapped LUNs: 1]
  |     |   o- mapped_lun0 ........................................ [lun0 fileio/disk1 (rw)]
  |     o- luns .................................................................. [LUNs: 1]
  |     | o- lun0 ............... [fileio/disk1 (/var/storage/disk1.img) (default_tg_pt_gp)]
  |     o- portals ............................................................ [Portals: 1]
  |       o- 0.0.0.0:3260 ............................................................. [OK]
  o- loopback ................................................................. [Targets: 0]
  o- vhost .................................................................... [Targets: 0]
  o- xen-pvscsi ............................................................... [Targets: 0]

この記事はopenSUSE Advent Calendar 2019の24日目です

※2020/01/26 追記 この設定をしてしまうと、Dockerが動かなくなってしまいます。詳細は現在調査中。まとまりましたら報告させて頂きます。※

GeekoMagazine 2019 冬号に、仮想サーバーをさくっと建てる方法を書かせていただいております。よろしくお願いいたします。

さて、私は実際にこの方法で立てた仮想サーバーを活用しているのですが、最近、家のルーターがipv4アドレスを仮想サーバーに割り振ってくれなくなってしまいました。

結論 ホストがbridgeしたパケットをフィルタリングするのを無効にする

sysctlで以下の設定を行った所、無事、DHCPでipv4が割り振られました。

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

1行づつ、sysctl -w で設定してもよいですし、ファイルに記述して、sysctl -p でそのファイルを読み込んでもOKです。

ただ、/etc/sysctl.d/ にファイルを配置しても、起動時に読み込んでくれません・・・ここは追って調査して、記事にしたいと思います。

これらは、bridgeのフィルタリングを無効にする設定とのことです。

もしかしたら、最近のカーネルのアップデートなどで設定が消えてしまったのかもしれません。私が忘れているだけで、以前はこの設定をしていたかもしれず、記事から抜けてしまっていて申し訳ないです・・・

橋本修太です

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

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

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

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

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

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

橋本修太です。

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

現象

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となっているもの、２つの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 ももう17日目ですね

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

アップデート方法

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

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

zypper dup --download-only
zypper dup

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

MySQL から MariaDB へ

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

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

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

+bind-address = 127.0.0.1
+log-error = /var/log/mysql/mysqld.log
+secure_file_priv = /var/lib/mysql-files
-sql_mode=''
+sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

SuSE Firewall2 から Firewalld へ

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

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

firewall-cmd --permanent --add-service https
firewall-cmd --reload

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をメンテナンスした話ですね。塩漬けに近かったサイトですので、色々と面白い話題が出てきそうです。こうご期待。

 

 

 

 

2017-10-21の、openSUSE.Asia Sumut 2017 で、「Zeroconf as simple name resolution for LAN」というタイトルで15分の発表を行いました。英語での発表ではなく、日本語での発表でしたけれど。
最初に日本語の資料を作っておいて、そこから英語に翻訳していったのですが、英語に自信が無いので、英語での発表を何回もしている人に添削をお願いしました。原形をとどめないくらいあちこち直されました。やはり、中学英語レベルで英語プレゼン資料を作るのは難があったみたいです…..
ともあれ、171021-en-opensuse-ribbon に発表資料を置きましたので、ご興味がある方はご覧ください。