個人事業主として開業しました

2018/11/30 / whywaita / 0 Comments

開業届を提出し、2018/09/01付けで個人事業主として開業しました。

現在は株式会社HERPにて業務委託契約で働いています。
当面は他の場所で働く予定もあるため長期で働くのはしばらくお受けできないかもしれませんが、単発でのお仕事などあればご相談できるかと思いますので、興味があればお気軽にお声がけください。

(さらに…)

ISUCON8 本戦にて優勝してきました #isucon

2018/10/22 / whywaita / 0 Comments

こんにちは。優勝班のwhywaitaです。

去る2018/10/20に行われたISUCON8 本戦にチーム「最大の敵は時差」として出場し、優勝しました。
チームメンバーは全員学生で、学生1位との同時受賞によりISUCON史上最高の賞金額となりました！！！

今までのあらすじはこちらです。

なぜにぽえむ
 
ISUCON8 予選に出場して予選突破した - なぜにぽえむ
https://whywaita.hateblo.jp/entry/2018/10/02/190000
isucon.net チーム「最大の敵は時差」で出場して、全体17位、各日上位3チームを除いた上位10チームの中に入り予選を突破した。 チームメンバーの1名がアメリカに留学中であり、更に日本のメンバーも毎朝7時出勤(学生なのに)という状況で、「全員タイムゾーンが違うじゃん！」という事でこのチーム名となった。

(さらに…)

色んなところでKubernetesを動かす本 のBooth販売が開始しています #技術書典

2018/10/10 / whywaita / 0 Comments

こんにちは。書籍出版班のwhywaitaです。技術書典5 にサークル側として参加してきました。

tl;dr

chofu-tech.booth.pm
 
色んなところでKubernetesを動かす本 - 調布技研 - BOOTH（同人誌通販・ダウンロード）
https://chofu-tech.booth.pm/items/1042442
Kubernetesを自宅・海外の激安VPSで動かす本です。 Kubernetes構築手順書としてもお読み頂けます。 CHANGELOG - 2018.10.09: 表紙の解像度を上げました

Boothにて電子版を500円で販売しております。是非お買い求めください！

また、一部環境においてzipパスワードが解除出来ないなどの不具合が初期バージョンにあり、現在は解決しています。
表紙の解像度が低い状態で表示されてしまう現象も観測されており(解決済み)、お手数ですが再ダウンロードして頂けると幸いです。

(さらに…)

#技術書典 5にてKubernetesについての本を出します

2018/09/23 / whywaita / 0 Comments

こんにちは。書籍発行班のwhywaitaです。

2018/10/08に開催される技術書典 5にて、調布技研名義でKubernetesの本を出すことになったので宣伝です。

技術書典：技術書オンリーイベント
技術書典5：調布技研 詳細
https://techbookfest.org/event/tbf05/circle/53000003
Kubernetes,クラウド

頒布場所は「か16」です。
上記ページからサークルチェックが出来るらしいので、是非どうぞ。

開催情報

  • 日時 2018/10/08 (月) 11:00〜17:00
  • 場所 池袋サンシャインシティ2F 展示ホールD（文化会館ビル2F）
  • 主催 TechBooster/達人出版会

頒布情報

「Kubernetesを色んなところで動かす本」という本を出します。
最近イケてるKubernetesなんですが、マネージドなKubernetesしか使ったことがない！という方が意外と多いのではないかなと思います。
そのような方に向けて文字通り「色んなところで」動かしてみる本となっています。

  • おうちKubernetesの作り方 by @nasa9084
  • 海外の激安VPSを知っていますか？ by @whywaita

頒布数などはまだ未確定ですが、在庫は異常に用意する予定ですのであまりお急ぎにならなくても購入可能な予定です。
また、PDF版の頒布も併せて行う予定ですので、ゆっくりブースまでご来場ください。

では、当日ブースでお待ちしております！

VMWare FusionのVMをCentOS上のKVMに移す

2018/07/27 / whywaita / 0 Comments

こんにちは。今日はmacOS上で動いていたVMをリソース潤沢なKVMサーバに移す話です。

バージョン

  • 移行元: VMWare Fusion 7.1.3
  • 移行先: CentOS 7.5
  • ゲストOS: Windows 7 Professional
  • 移行元のスペック情報はあまり残さない方針
    • 後ほど手で直そうと思っていたので

VM移設

macOSからのエクスポート

VMWare Fusionのディスクを操作するには vmware-vdiskmanager を使う必要があります。既にVMWare Fusionを利用しているmacOSにはパッケージ内にコマンドがあるので、これを利用しましょう。

$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager

まず最初に、ゲストOSのディスク名を英語の物にしてしまうのをオススメします。違うOS間を移動する都合上、漢字や片仮名を用いたファイル名は避ける方が吉です。デフォルトでは”仮想ディスク”という名前になっていることが多いので注意が必要です。
vmware-vdiskmanager にはディスク名を変更するコマンドがあるので、これを使います。

$ cd Documents/Windows\ 7\ x64.vmwarevm/  # もしVMの保存先を変更していたらそちらに
$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -n "仮想ディスク.vmdk" vdisk.vmdk

この際、仮想ディスク-s001.vmdkのようなファイル名のファイルが多くあるかもしれませんが、気にせずサフィックス無しのファイルのみ指定すれば問題無いです。

-s001 のようなファイルは、分割されたOSファイルです。ファイルシステムによっては1つの巨大なファイルを扱うより数GB程度のファイルをいくつか扱う方が性能が良いので、この機能が有効化されている場合が多いと思います。

これらを1つのファイルに纏めるコマンドが以下です。

$ /Applications/VMware\ Fusion.app/Contents/Library/vmware-vdiskmanager -r vdisk.vmdk -t 0 vdisk-full.vmdk

分割されているファイルを1つに纏めたファイルを出力するコマンドです。単純にVMサイズと同じディスク容量のファイルが生成されるので、ディスク容量にはお気を付けください。

このファイルを入手したらエクスポートは成功です。scpコマンドなどでサーバに送りましょう。

$ scp vdisk-full.vmdk whywaita@server:

KVMサーバへのインポート

既にQEMU/KVM環境が完成している場合はqemu-imgコマンドが利用できます。このコマンドでOSイメージを変換します。
変換後のファイル形式はお好みで。私はqcow2でうまくいきました。

$ qemu-img convert -f vmdk -O qcow2 vdisk-full.vmdk image.qcow2

あとはお好みのVM管理コマンドで既存ディスクから起動すれば成功です。私はvirt-managerでサクッと起動しました。

CentOS上でvmware-vdiskmanagerを起動する

上記の方法ではmacOS上でVMディスクを纏めましたが、諸般の理由でこの作業をLinux上で行いたい場合があります。例えばストレージの都合とか。
その場合は以下のリンクが参考になります。

適切なライブラリを、適切な場所にシンボリックリンクすると動きます。詳細は割愛しますが、以下のようなファイル配置になると思います。

.
├── vmware-vdiskmanager-linux.7.0.1
├── libdir
│   └── lib
│       ├── libcrypto.so.0.9.8
│       │   └── libcrypto.so.0.9.8 -> /usr/lib/libcrypto.so.0.9.8e
│       └── libssl.so.0.9.8
│           └── libssl.so.0.9.8 -> /usr/lib/libssl.so.0.9.8e

おわりに

無事にリソース的に余裕があるKVMサーバにVMを映せました。これでまた暫く戦えそうです。

今回はゲストOSがWindowsでしたが、このままだと使う場合にもう少し工夫が必要な場合があります。特に仮想GPUが鬼門で、適当なGPUをパススルーするかRemoteFXが使えるようにするかなどがあります。
RemoteFXが使えれば一番楽なのですが、その場合はWindows Serverを入れたりWindows 7からWindows 10に上げるなどが楽なようです。私も何か考えないとな…。

参考文献

kubernetesに自分のコードがマージされるまでのフロー

2018/06/15 / whywaita / 1 Comment

はじめに

こんにちは。kubernetes班のwhywaitaです。皆さんkubernetesやっていますか？

kubernetes を使う場合、アプリケーションをデプロイする際にミドルウェアの管理に悩むことがあり、その解決策として様々なアプリケーションが開発されています。1

その中でも私はHelmがお気に入りです。
自分のアプリケーションを含めた全てのデプロイをHelmで賄うのには向いていないように感じますが、アプリケーションで必要なミドルウェア(DB、KVSなど)を立ち上げる用途としてはかなり優秀なプロダクトだと思います。

そのHelmでインストールすることの出来るミドルウェアの単位をchartと呼びます。chartが集まったものをリポジトリと呼び、 stable リポジトリと incubator リポジトリはGitHub上で公開されています。

GitHub
 
kubernetes/charts
https://github.com/kubernetes/charts/
charts - Curated applications for Kubernetes

GitHub上で公開されているので、もし何らかの修正を行いたい場合はPull Requestを送る事が出来るのですが、一般的に使われているフローではなく、一定のルールを満たす必要があります。
あまり日本語情報が無いように思ったので、今回は実際にkubernetes OrganizationであるHelmにPull Requestを送り、無事マージされるまでのフローを書きます。

バージョン

Pull Requestであるためそれほどアプリケーションのバージョンは依存しませんが、念のため作業環境のバージョン書いておきます。

  • kubernetes: v1.10.3
  • kubectl: v1.10.4
  • helm client: v2.8.2
  • helm server: v2.8.2

Pull Requestフロー

まずは、kubernetesが定めるContributor License Agreements、略してCLAの提出が必要となります。
これはkubernetesにコントリビュートする際に満たすべき制約に、コントリビュートした全員が承諾する事を担保するものです。

kubernetesはCloud Native Computing Foundation(CNCFと呼ばれます)に入っているプロジェクトの1つであり、CNCFはLinux Foundationに入っているプロジェクトの1つです。
このような関係を持つため、kubernetesのCLAは現状Linux Foundationのシステムを用いて、CNCFのCLAを提出すれば認可されます。

Linux Foundationアカウント発行

Linux FoundationのCLAには個人向けと企業向けの2種類が存在しています。私は個人としてCLAの提出を行ったため、今回は個人向けの作業をお伝えします。

下記のURLから、Linux Foundationのアカウントを発行します。
https://identity.linuxfoundation.org

ソーシャル連携でアカウントを作成しても良いですし、Linux Foundationのアカウントを新規に作っても構いません。
最終的にLinux FoundationのアカウントとGitHubのアカウントを紐付ける必要があるため、GitHub連携でログインしておけば若干手間が減るかもしれません。
私はLinux Foundationのアカウントを作り、その後GitHub連携を行いました。勿論この方法でも問題無くCLAの提出は可能です。

アカウント作成中にFirst nameとLast nameを入力する欄がありますが、基本的には公開されず、usernameで書いた部分のみ公開されます。

また、この時設定するメールアドレスにはGitHubのコミット上で用いているメールアドレスと同じものを利用するようにしてください。コミットとの紐付けに利用しているようです。
現在利用しているメールアドレスは以下のコマンドで確かめられます。

$ git config user.email
whywaita@whywrite.it  # 私の場合

最後に、GitHub連携以外の方法でアカウントを作成した場合は、こちらからGitHub連携を追加しておいてください。

CLAを提出し、CNCFグループに入る

以下のURLから、自分のLinux FoundationアカウントをCNCFグループに参加させることができます。

https://identity.linuxfoundation.org/projects/cncf

アカウント作成、およびGitHub連携が既に済んでいる場合、以下のような画面が出ます。

名前とメールアドレスが間違っていなければ、そのままSubmitを押します。
すると、登録しているメールアドレスにHelloSignというサービスからメールが届きます。

HelloSignは電子署名システムの1つで、実際に紙を印刷してサインをせずともWebブラウザのみで電子署名が行えるシステムです。
Review & Signのリンクからページに飛ぶと、CLAで承諾すべき項目が実際に表示され、問題無ければ項目を埋めて提出します。

CLAの文章自体はこちらに公開されています。
HelloSignのサービスを利用したくなかったり、紙を用いた証拠が欲しい場合は、PDFをスキャンして info@cncf.io に送信したり、Linux Foundationのオフィスに国際郵便で送付することも可能です。CLAの文書にどのような手法を用いられるのか記載されているので、CLAを提出する際にご確認ください。2

HelloSign上でCLAを提出した場合、提出に成功したことがメールで通知され、HelloSign上のシステムでも提出が完了したことを確認できます。
私が提出した時は、数分程度で提出完了のメールが届きました。

これにてCLAの提出は完了です。

Pull Requestの作成

これでようやくコードを書くことができます。
ここからは実際に私が出し、マージされたPull Requestを例としながら説明していきます。

GitHub
[stable/datadog] add nodePort value in datadog template by whywaita · Pull Request #6024 · kubernetes/charts
https://github.com/kubernetes/charts/pull/6024
What this PR does / why we need it:helm user become able to set fixed dogstatsd nodePort.if using type: NodePort service, I want to use fixed nodePort.But, NodePort is random when nodePort is bl...

Pull Requestの作り方(Forkして、ブランチを切って、など)は一般的なフローと同じですので割愛させて頂きます。

実際にPull Requestを出すと、k8s-ci-robotというユーザが自動的にラベル付けなどを行ってくれます。
このユーザはkubernetesチームが用意した自動化用のbotシステムであり、そのPull Requestの状況等を管理してくれます。

3

CLAの提出が正しく出来ていれば、この段階でこのようなメッセージが来ます。

レビューしてもらう

Pull Requestが自分の中でレビューして貰って問題無い状態になったら、レビューアーをアサインしてレビューしてもらいます。

レビューアーに指定するべき人がランダムで提案されますが、基本的には担当者全員アサインして良いようです。
この時のアサイン対象者ですが、誰でも良いという訳ではなく、chart毎に指定するべき人が決まっています。例えば私が今回出したdatadogであれば、以下のURLにあるOWNERSファイルに書かれています。

https://github.com/kubernetes/charts/blob/master/stable/datadog/OWNERS

GitHubのシステム上、ブラウザ上からアサインすることも技術的には可能なのですが、アサインの状態を可視化するためにk8s-ci-robotにアサインしてもらう運用になっているようです。
/assign コマンドを実行します。実際のコメントはこちらです。

その後はレビューアーの指示に従い、修正や議論を行います。4

実際にマージする実行をするのはk8s-ci-robotですが、レビューアーに lgtm ラベルと approve ラベルを付けてもらう必要があります。
その時々でラベルの付ける順番などは変わるようなので、適宜レビューアーに聞いてみると良いかもしれません。
私も聞いた結果ラベルが付与されました。

最終的に問題がないと判断されれば、k8s-ci-robotによってマージされます！

おわりに

このフローを踏むことで、無事kubernetesグループに貢献することが出来ました。
OSSを使うだけでなく、OSSに貢献することで、OSSの素晴らしいライフサイクルを回せていければと思います。

また、本記事公開以降コントリビュート手順が変更される可能性があります。
もし不明な点があった場合は、原文であるこちらを参照してください。

HERP広告

この記事は株式会社HERPの勤務中に書かれた物である。
株式会社HERPでは今後もOSSに貢献し続けます。

株式会社HERPは様々な職種での人材を募集しています。

また、この広告箇所は本の虫のオマージュです。

  1. Kubernetes YAMLの壁 | SOTA ↩
  2. ちなみに私が提出した際のCLAはこのコミットです。 ↩
  3. robotは既に終了した自分のコメントに関しては消してしまうので、私のメーラーに来ていた通知メールのスクリーンショットです ↩
  4. ここが一番難しいかもしれませんね… ↩
1 2 3 4 5 … 13