Kubernetesで何らかの永続データを保存する場合、通常PersistentVolumeと呼ばれる永続ストレージを使用します。Persistent VolumeはNFSなどのネットワークストレージを直接指定することもできますが、ボリュームを手動で用意する必要があり、非常に面倒です。 そのため、ブロックストレージサービスをバックエンドとしてdynamic provisioningと呼ばれる、自動でボリュームを作成する機能も用意されています。 dynamic provisioningを使用する場合、バックエンドのprovisionerをStorageClassと呼ばれるリソースに登録しておきます。クラウドでKubernetesを使用している場合はAWS EBSなどを使用するでしょう。 オンプレミスや自宅でKubernetesを使用している場合、GlusterFSやCeph RBDを使用することができます。今回はCephを使用してPersistentVolumeを作成するまでの流れを説明しましょう。 下準備 今回はOpenNebula上にCentOS 7のVM(2GB RAM/1Core CPU)を3台用意し、構築を行いました。バージョンはmimicです。/dev/vdbにCeph用のディスクがあるとします。 それぞれ、Chronyで時刻同期の設定、firewalld無効化、SELinux無効化状態で構成しました(本番ではちゃんと設定してくださいね！)。 また、ceph-1 ceph-2 ceph-3という名称でアクセスできるよう、hostsファイルを書いて、SSHの鍵もコピーしました。 インストール まずは公式サイト を参考に各サーバへリポジトリの追加をします。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 /root@ceph-N# rpm --import 'https://download.ceph.com/keys/release.asc' /root@ceph-N# cat < EOF > /etc/repos.d/ceph.repo [ceph] name=Ceph packages for $basearch baseurl=https://download.ceph.com/rpm-mimic/el7/$basearch enabled=1 priority=2 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.asc [ceph-noarch] name=Ceph noarch packages baseurl=https://download.ceph.com/rpm-mimic/el7/noarch enabled=1 priority=2 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.asc [ceph-source] name=Ceph source packages baseurl=https://download.ceph.com/rpm-mimic/el7/SRPMS enabled=0 priority=2 gpgcheck=1 gpgkey=https://download.ceph.com/keys/release.asc EOF リポジトリの追加ができたら、各サーバへceph-deployをインストールします。 ...

調布技研、という怪しい団体がありまして、私はそこに所属しています。調布技研は主にSlack上で与太話をしている集団で、インフラとかの検証なんかを共同でやっていたりします。 来る10月08日に、技術書典 という、技術系同人誌のイベントが開催されますので、そこで「色んなところでKubernetesを動かす本 」という同人誌を出す予定です。 先ほど、無事入稿が完了しました。 私は「おうちKubernetesの作り方」と題して、自宅を含むオンプレでKubernetes環境を作るためのあれやこれやを執筆しました。ベースとなっているのは「趣味サーバーのインフラをKubernetesで整えた件 」でもご紹介した私の自宅Kubernetes環境で、小規模ならばプロダクションにも使える環境です。 物理本1冊500円(電子版つき)、電子版のみは400円での頒布となる予定ですので、ぜひお買い求めください。場所はか16です。 なお、冒頭の画像はタイトルをミスった表紙です。

レギュレーション タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。 — laiso?? (@laiso) August 1, 2017 本題 私事ですが、2018-09-20を以て日本仮想化技術株式会社を退職し、2018-10-01付けでLINE株式会社へ就職します。 以上。

ingress-nginx を使用している際に、nginxに何か設定をしたいと思ったとき。 例えば、nginxは初期状態では、アップロードできるファイルの上限は1MBなのですが、これをもっと大きくしたいとき、nginxでは次のように設定します。 client-max-body-size 5m; これをingress-nginxでも設定したいと思ったとき、どうしたら良いか。 まぁ、簡単な話で、annotation で設定値を与えてあげれば良いです。 この場合だと、次のようにします。 1 2 3 metadata: annotations: nginx.ingress.kubernetes.io/proxy-body-size: 5m 設定できる値はingress-nginxのドキュメント に記載されています。 client-max-body-sizeを指定するのにproxy-body-sizeと設定することに注意です。

過日、かねてより準備してきたbuilderscon tokyo 2018 が開催され、そして終了しました。 Opening 例年、buildersconでは主催の@lestrrat さんがオープニングでお話をしているのですが、今年はなんと動画を作りました。 それがこちら。 オープニングムービーなので7分程度ですが、かなり気合いの入った動画となっております。詳しい情報は「builderscon tokyo 2018 オープニング作成の裏側」 で紹介されています。 記事中でも解説されていますが、この動画、「The Stanley Parable」というゲームのオマージュとなっています。残念ながら開催時点で私はプレイしたことがなかったのですが、昨日プレイしました。面白い。ナレーションがナレーションのくせにこう、感情的なんですよね。怒ったり、悲しんだり。是非皆さんもプレイして(もしくはYoutubeとかでプレイ動画をみて)みてください。 Talk 2016年の初開催からコアスタッフとしてやってきた私ですが、今年はスピーカーとしても参加することが出来ました (スライドはこちら )。残念ながら一度は落選しており、キャンセルされた枠に滑り込む形でしたが、2016年はCfP落選、2017年は業務都合で当日参加出来ず、そして2018年は穴埋め登壇と、着実に進歩しています。来年は是非、きちんと「通った」スピーカーとして参加したい・・・！ twitterで私が話している時間帯のツイートを見ると、「Kubernetesがゲシュタルト崩壊」と複数の方に書かれていて、メダパニを書けてしまった気分です。しかし話題が話題なだけに仕方なかったんや！ スタッフとして 上でも書きましたが、今年は三年目のコアスタッフ参加でした。初年は北海道からのリモート参加、去年は当日に絡む仕事は出来ず、だったので、実質まともに参加したのは初めてです。 いくつかoctav(buildersconウェブサイトのバックエンドAPIサーバ)の修正を書き(マージされたとは言っていない)、当日スタッフのまとめ役をしたりしました。 当日スタッフのまとめは正直上手く出来たとは言えず、他のスタッフ(Discordの設定とか当日スタッフの担当割りの細かい調整をしてくれたtoriiさん、諸々印刷などしてくれたuessyさんに多大なる感謝を・・・)の助けを得てなんとか大きな問題無く終えることが出来ました。 タスクはまだ残っているので、これから一週間くらいかけてがしがしやっていきます。 来年は今年よりももっとコミットしていきたい所存です。 来年に向けて buildersconのコアスタッフSlackでは、すでに来年の企画に向けて侃々諤々といった様相です。buildersconは他のカンファレンスに比べ、自由度が高い(と思っています)ので、何か面白いことをやりたい、と思ったかたは是非スタッフに参加してみてください。(そのうちスタッフ募集が始まる・・・はず)

fitbit versa を使い始めて 3日ほど経ったので、現時点での感想をば。 電池の持ちは前情報通り1日で20%〜25%減る程度 常時接続・Keep-AliveウィジェットはともにON 夜にお風呂/シャワー上がってから、翌日お風呂/シャワーに入るまで、で1日。 お風呂/シャワーの間に充電100% 画面つける動作の反応が悪い、という情報があったが、そんなに気にならない 歩数計は少し過敏な様で、実際歩いた歩数より多い気がする PCでの作業でも反応してる気がする 本体が防水でも、バンドが水を吸うと水に過敏になる 明日からはCLASSIC BANDに取り替えてみる 結構変な方向を向いてしまう ベルトをもう一つ締めれば回らなくなるけど、今度は少しきつい 安い画面保護ガラスフィルム を買った 一部のレビュー通り、縁が若干浮いている様だけど、気にならないレベル 腕時計をつける習慣が無かったことは、お風呂の時以外常時つけていると案外気にならない Androidアプリは若干バグってる 後述。 versa上で動くアプリはあんまり無い もっと増えたら楽しいのに・・・・(しかしどんなアプリが欲しいかというと思いつかない) versaの時計盤の種類も(よさげなのは)そんなに多くない まぁ、頑張ろう 階数カウントは何を基準にカウントしてるのか謎。 天気予報、スマホ側で設定できる画面があるけど結局現在地しか表示できてない。 よくわからん。 アラーム、もう少し長く鳴って欲しい Androidアプリのバグ Android用のfitbitアプリが若干バグってました。すでに報告済みですが、まぁパッとは治らない様子。仕方ない。 具体的には、睡眠のページを開き(このときは問題ない)、睡眠の日別詳細を開いて戻ると、なんとデータの一覧が増殖する。 尚動作環境はZenfone 5Z、Android 8.0.0。 睡眠のページ。問題はなさそうに見える。 睡眠の日別詳細ページを開いて戻ってきた画面。同じデータだが、画面表示が増えている。 もう一度詳細を開いて戻ってきた画面。増える。増える・・・。

TR;DR KubernetesのServiceで、Internal LoadBalancerってのがあるので、それを使うと良い Internal LoadBalancer 皆さんはEKS、もう使ってますか？私は使っています。業務システムをリプレースで新規開発する的な案件で、新システムの基盤がEKSという感じです。EKSはネットワークが素敵に気持ち悪い感じになっており、普通はKubernetesのクラスタ内部っていうのは、外側と別のサブネットを作る訳なんですが、なんとEKSが所属するVPCと同じサブネットで接続できるようになっています。 そんなわけで、同一VPCに存在したり、VPC PeeringしたりなんかしちゃってるEC2インスタンスとEKS上のPodはIPアドレスベースでは普通に接続がとれちゃったりするんです。 EKS上のアプリケーションから、EC2インスタンスへアクセスしたいときは、普通にEC2インスタンスのIPアドレスやら内部エンドポイントへアクセスすれば良いですね。EC2インスタンスが動きっぱなしならまぁさほどIPも変わらんでしょう(雑)。 しかし逆は問題です。PodのIPは勿論割り振られてはいますけれど、これはPodが再生成されると勿論変わってしまいます。アプリケーションは動きっぱなしだから変わらない、なんて言うこともできないです。EC2インスタンスはインスタンス上でアプリケーションの更新なんかもしちゃうかもしれないですけど、EKS上のPodに乗ったアプリケーションの更新は普通、Podの再作成が伴います。Podの再作成が起きると、勿論IPが変わります。 そうすると、やはり考えるのはServiceをつくることですね。外部からアクセスするためにはそうしますから、同じように考えるのが普通です。 しかし、ここで問題が発生します。普通に外部向けに公開するのと同じようにServiceを作成すると、グローバルIPが当たってしまい、プライベートIPベースで接続できる状況では接続ができないのです。困った。 まぁドキュメントちゃんと読めよって話なんですが、Kubernetesのドキュメント を読むと、Internal LoadBalancerってのがちゃんと書いてあります。AWSの方のドキュメントには無かったのでちょっと盲点でした。annotationで次の様に指定します。 1 2 3 4 5 6 # ... metadata: name: my-service annotations: service.beta.kubernetes.io/aws-load-balancer-internal: 0.0.0.0/0 # ... これだけで、type: LoadBalancerで作成されるELBが内部向けのものになります。internal-なんちゃらみたいなエンドポイントです。IPアドレスもしっかりプライベートIPです。最高。後ろの0.0.0.0/0のところで、アクセスできるIPレンジ制限できるのかなーなんて希望的観測を持ちましたが、全然関係ありませんでした。 ちょっと気持ち悪いのは、普通にパブリックDNSで名前引きができてしまうことですかね。全然関係ない外部のネットワークとかでも(パブリックDNSに名前があるので)名前解決ができてしまって、かつプライベートのアドレスが帰って来るという不思議な体験をすることができます。 1 2 3 4 5 6 7 8 9 10 11 $ nslookup internal-xxxxx.us-west-2.elb.amazonaws.com 1.1.1.1 Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: internal-xxxxx.us-west-2.elb.amazonaws.com Address: 192.168.187.214 Name: internal-xxxxx.us-west-2.elb.amazonaws.com Address: 192.168.222.128 Name: internal-xxxxx.us-west-2.elb.amazonaws.com Address: 192.168.109.84 うーん、まぁ実害は無いんでしょうけど。 ...

スマートウォッチ的なものが欲しいなーと思ったので、fitbit versa を購入しました。 fitbit versaはその名の通り、fitbit が今年(2018)の6月に発売したスマートウォッチです。トップの写真からもわかるように、若干Apple Watch に似ています。 元々、Huawei Watch が欲しいなーと数年前に思っていたんですが、(当然ながら)新しいモデル が出ており、これがまた初代のHuawei Watchとは全く方向性の違うスポーツタイプ。これはちょっと・・・と言うことでPebble もいいな、と探してみると、いつの間にやらサポートが終わってしまっていました。よくよく調べると、Pebbleはfitbitに買収された とのことでした。かといってApple Watchを買うかというと、私はAndroid ユーザですから、そういう選択肢はありませんでした。 そうこう考えながらいろいろ検索したりなんかしていたんですが、fitbit versaが実質的にPebbleの後継であるという情報を見たり聞いたり しました。お値段もお手頃で、これならまぁいざ微妙でも、買い換えもできるかな、という気持ちもあり、購入に踏み切りました。(fossilの新しいやつもよさげなんですが、ドルで見た金額と円で見た金額が大幅に違って萎えました) 外箱はこんな感じです。fitbit versaは、通常モデル(シリコン？ゴム？のバンド)が3種類と、SPECIAL EDITION(布バンド)が2種類の計5種類で展開されています。元々海外モデルではSPECIAL EDITIONにのみNFCが搭載されているという違いがあったようなのですが、日本版では機能的違いは無いようです。 通常モデルの黒と、SPECIAL EDITIONのグレーですごく悩みました。本体の色はグラファイトの方が良さそうだし、バンドも布の方がよさげに見えたんですが、布バンドは濡れたら乾くまで時間かかりそうなので、ゴムバンドのほうが良いのかな・・・と・・・(店頭で悩み続けたので若干怪しかったかも？)。でもまぁ、本体の色はブラックよりグラファイトの方がよさげでしたし、ゴムバンドは純正の交換バンドとして売ってるから、後で買うこともできるか、ということでSPECIAL EDITIONのグレーにしました。今回ビックカメラで買ったんですが、ビックカメラではカードの様なものをレジに持って行くんです。で、商品を受け取ってみたら箱の右下に「PLUS EXTRA CLASSIC BAND」の文字・・・。 帰ってから開封してみたら、案の定通常モデルと同じクラシックバンドが付属してました。ついてるなら早めに言ってほしかった・・・あれだけ店頭で悩んだ私の時間とは・・・。! 本体の画面を保護していたフィルムを取ってみて気づいたんですが、小さなクッションのようなものがついてました。ボタンが押ささらない様にとの配慮なんでしょうけど、こういう細かい気遣いは初めて見たので少しだけ感動しました。 非常に軽く、そしてエッジが削られているので薄く見えるため、非常にスマートです。写真で見る限りではベゼルが結構幅広なのが気にかかった(最近はZenfone 5Zを使っていることもあり、ベゼルは小さい方がいいなーと思っていた)のですが、実際画面をつけてみると、意外と気になりませんでした。 元々腕時計など、腕に何かをつけるという習慣がないので、どうなるかわかりませんが、しばらく使ってみようと思います。

趣味でサーバー運用をしています。札幌在住の大学生時代から運用を開始し、引っ越しに伴い朝霞へ移設、現在はコミュニティで使用している自宅外のラックへ移設されましたが、変わらず動いています。 この「趣味サーバー」は購入当初からKVMをベースとした(OpenNebula を使用しています)プライベートクラウド基盤として使用してきました。今も変わらずベースはOpenNebula/KVMなのですが、この度晴れてKubernetes を中心とした構成に組み替えたのでご紹介します。 尚、サーバ台・電気代・インターネット代を除くソフトウェア料金は基本的に無料で済んでいます。 物理層 このプライベートクラウド基盤は3層で構成されています。 その最も下の層が物理層です。その名の通り物理サーバそのものですね。物理サーバとしてDELLのR410(ヤフオクで1万弱で購入・4コア8スレッド×2、メモリ16GB)とDL360Gen6一号機(会社の処分品をもらってきた・4コア4スレッド×2、メモリ24GB)、DL360Gen6二号機(会社の処分品をもらってきた・4コア8スレッド×2、メモリ24GB)の三台で、それぞれubuntu 16.04LTSがインストールされています。落ち着いたら18.04LTSにアップデートしたい。 基本的に電源やLANは冗長化されておらず、電源やNICに問題があると即死亡となります。 VM層 物理層の上に構成されているのがVM層です。OpenNebula/KVMを使用しており、Web UIからポチポチッとVMを作成できます。今回Kubernetesで整える前は、VMとしてnginx インスタンスを作成し、外からの80/443ポートへのアクセスを捌くリバースプロキシとして使用していました。本ブログも長らく単体VM上のDocker コンテナとして稼働していました。基本的にVMにはCentOS 7をインストールしています。 今回の構成変更で、VMは基本的にKubernetesのノードとして使うように変更、直接VM上で動作しているのはオブジェクトストレージを提供するminio とブロックストレージを提供するGlusterFS のみとなりました。 尚、GlusterFSクラスタの構成にはheketi を使用しました。 コンテナ層 最も上の層がコンテナ層です。ここまでの話からわかるように、Kubernetesクラスタを構成しています。四台のCentOS 7をクラスタノードとして使用、Kubernetes自体の構成管理はkubespray を使用しています。現在はKubernetes 1.11.1です。本ブログもKubernetes上のコンテナとして動いています。 Persistent VolumeとしてVM上に構成したGlusterFSを使用、本ブログ等のバックアップ先としてminioを使用しています。 当初はVM上に構成したnginxインスタンスをそのままリバースプロキシとして使用していましたが、本ブログを含めたアプリケーションを順次Kubernetesクラスタ上のコンテナとして移設していった結果、nginxのVMだけ別になっていることに不便を感じるようになりました(リバースプロキシの設定は手作業で設定しなければなりませんし・・・)。しかし、VM上のnginxリバースプロキシを廃するためには、二つの問題点がありました。 素KubernetesではIngress が使用できないため、ホスト名ベースの振り分けが出来ない Let’s Encrypt の証明書を管理するVMがいなくなる これらを解決しないことにはnginx VMを削除できません。 解決のためにまず、kind: Ingressを使用するための実装としてingress-nginx を使用することにしました 。Ingressが使用できるようになることで、クラスタ外のリバースプロキシを挟まずともホスト名ベースの振り分けが出来るようになります。 ingress-nginxはService type: NodePortでも使用できるのですが、折角なのでService type: LoadBalancerを使用したいですよね？type: LoadBalancerを使用するための実装としてMetalLB を使用することにしました 。これにより、ingress-nginxに対してクラスタ外のIPアドレスを割り当てることが出来るようになります。 次に、Let’s Encryptの証明書を管理するため、cert-manager を導入しました。cert-managerはkubesprayの導入時にアドオンとしても導入することが出来、今回はkubesprayのアドオンとして導入しました。これはその名の通り、証明書をKubernetesのリソースとして管理することが出来るツールです。最初はLet’s Encryptのacme api v02に上手くアクセスできない、ワイルドカードでの証明書取得が出来ないなど躓きましたが、Let’s Encryptに上手くアクセスできない問題は最近のkubesprayで比較的新しいバージョンのcert-managerを導入することで解決できました。ワイルドカードでの証明書が取得できない問題は、元々webroot(HTTP01)で証明書を取得していたのが原因のため、DNS01へ切り替えました。Gehirn DNS を使用していましたが、上手くいかなかったためCloudflare DNS に切り替え、事なきを得ました。 これらにより、nginx VMを廃し、ルーターでの80/443のNAPT設定をすべてKubernetesクラスタへと向けることが出来るようになりました(OpenNebulaやminio等へのアクセスはtype: ExternalNameを使用)。 VMがぐっと減り、ストレージ用途以外のVMを直接触らなければいけないことも減りました。めでたしめでたし。 使っているものまとめ Ubuntu CentOS Kubernetes (GitHub ) ...

TL;DR Alertmanagerの設定には一部Secretが含まれる バージョン管理システムに入れたくない initContainerでconfdを使って設定ファイルを生成する Alertmanagerの設定の一部をSecretに格納できる confd kelseyhightower/confd は非常に軽量な設定ファイル管理ツールです。基本的にはテンプレートエンジンですが、多くのバックエンドデータストアからデータを持ってきて、設定ファイルに書き出すことが出来ます。 また、事前処理や事後処理を行うことが出来るので、例えば設定ファイルを書き換えたあと、リロードする、というところまでconfdで行うことが出来ます。 Install Go言語で書かれているため、インストールは非常に簡単で、バイナリをダウンロードしてきて実行権限を与え、パスの通ったところに置くだけです。バイナリはリリースページ からダウンロードすることが出来ます。 使用方法 confdを使用するためには、三つのものを用意する必要があります。 テンプレートリソース テンプレート データストア テンプレートリソース テンプレートリソースには、どのテンプレートを使用して、どんなキーでデータストアからデータを取り出し、完成した設定ファイルをどこに置くのか、事前処理・事後処理はどんなものかを記述します。書式はTOMLで、慣れ親しんだ(慣れ親しんでない？)iniファイルの様に気軽に書くことが出来ます。/etc/confd/conf.d以下に配置します。 テンプレート テンプレートはその名の通り、設定ファイルのテンプレートです。ここに、データストアから取り出したデータを合わせて設定ファイルを作成します。書式はGo言語のtext/template に準じます。/etc/confd/templates以下に配置します。 データストア そして、データストアにデータを入れる必要があります。 confdは、データストアとして、次のものをサポートしています(2018/08/20現在) etcd (GitHub: coreos/etcd ) consul (GitHub: hashicorp/consul ) dynamodb redis (GitHub: antirez/redis ) vault (GitHub: hashicorp/vault ) zookeeper (GitHub: apache/zookeeper ) rancher metadata-service (GitHub: rancher/rancher , rancher/metadata ) AWS Systems Manager パラメータストア 環境変数 ファイル Alertmanager Alertmanager はPrometheus からのアラートを受け取り、適切にハンドルするためのアプリケーションです。Alertmanagerの設定はYAMLで記述するのですが、SMTPのパスワードやSlack のIncoming Webhook URL 等、平文でバージョン管理システムに入れるのは躊躇われるデータを含みます。しかし、環境変数などから設定をすることも出来ないため、平文で記述するか、何らかの方法で設定ファイルを編集してから使う必要があります。 特に、Prometheus/AlertmanagerはKubernetes と併せて使用されることが多いため、出来ればKubernetesのSecret機能を使用したいところです。 そこでconfdをinitContainerで使用して、設定ファイルを生成します。 まず、テンプレートを作成します。Alertmanagerの設定ファイルを用意し、後から挿入したい部分をテンプレート文字列で置換しておきます。 1 2 3 4 5 6 7 8 9 10 global: slack_api_url: {{getenv "ALERTMANAGER_SLACK_URL"}} route: receiver: slack receivers: - name: slack slack_configs: - channel: "#alert" 今回は例なので、細かい設定の一切を省いた形にしました。上記の内容で、alertmanager.yml.tmplとして保存しました。 ...