tsub

Apple Silicon Mac で複数 Terraform バージョンを管理するために asdf-terraform-build を作った

こんにちは、インフラエンジニアの <a href="http://blog.hatena.ne.jp/tsub511/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/tsub511/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:tsub511</a> です。実は去年の 1 月から 1 年間育休を取っており、今年の 1 月から復帰していました。

復帰してから記事を書くのが遅くなってしまいましたが、社内勉強会で話したスライドや育休から復帰してみてどうだったかをまとめてみました。

<h2>社内勉強会で話した</h2>

今年の 3 月頃に社内の技術勉強会 <a href="https://developer.feedforce.jp/archive/category/FFTT">FFTT</a> で発表しました。
(技術勉強会という立て付けですが、技術に限らず本人が話したいことを話して良い場です)

<script async class="speakerdeck-embed" data-id="e196f600db8d42c4841227d36b76f3b5" data-ratio="1.77777777777778" src="//speakerdeck.com/assets/embed.js"></script>


なぜ一年間の育休を取得したのか、育児の知見などがスライド内に書いてありますので気になる方はご覧ください！

ちなみに当時のスライド内ではねんねトレーニング (ネントレ) をやっていると書いてありますが、実は現在はやってません。

理由はネントレの効果が見られなくなったためです。

今年の 4 月くらいから寝付きが悪くなり、胸や背中をトントンしないと寝てくれなくなってしまいました。

それ以降夜通し寝てくれないことも増えてしまい、再度ネントレにチャレンジしましたが夜泣きは改善されなかったため、夜泣きの原因は寝かしつけ方法と直接関係ないのでは？と思いネントレをやめました。

ちょうどその頃から奥歯が生え始めていたので、それが原因だったのではないかとは思っています。

ここ最近は歯の痛みが落ち着いたのか、夜泣きが少し減ってきたような気がします。と思ってたらまた夜泣きが復活しました... 😭

やっぱりセルフねんねしてくれてた頃と比べて寝かしつけにかかる時間は増えましたが...

寝かしつけで悩んでいる方にとって少しでも参考になれば幸いです。
(自分はめっちゃ悩んだ)

<h2>育休から復帰した感想</h2>

スライド内でも触れていましたが、やはり一番感じたことは一年間というそれなりに長い期間にも関わらず、普段有給を取るのとそこまで大きく変わらないくらいの感覚でした。

もちろん育休を取るという話をしてからチーム内での調整は行いましたが、取得する障壁は特にありませんでした。
チームメンバーも育休は取得する前提で育休期間中はどう進めていくのか、という話にフォーカスしている印象でした。

そして、一年間の育休を終えて復帰する際にもすんなり業務に戻ることができました。

人事やチームメンバーが自分の育休中の変化を事前に記事にまとめてくれていたこともあり、キャッチアップも大体 2 週間くらいで完了しました。

復帰がスムーズにいった理由の 1 つにチーム体制や使用技術に大きな変化がなかったことも大きいと思います。

以下の記事でも軽く触れていますので良ければご覧ください。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmedia.feedforce.jp%2Fn%2Fn98075add5154" title="「謙虚な人が多い」「有休みたいに育休がとれる」エンジニアが語る、フィードフォースのぶっちゃけ裏話｜フィードフォースのnote" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

<h2>働き方の変化</h2>

育休取得前後 (子どもが生まれる前後) での大きな変化の 1 つとして、働き方がかなり変わりました。

子どもが生まれる前は 10:00 ~ 19:00 で働いており、モチベーションや体力がある日は少し長めに働いたり、反対に効率の悪い日は早めに退勤したりという働き方をしていました。

子どもが生まれた後は保育園や子どもの就寝時間の都合で 8:00 ~ 17:00 で働くこととなり、保育園の送り迎えや夕飯の支度などがあるので長めに働くということができなくなりました。

また、プライベートの時間で技術的な勉強をやることもほとんどなくなってしまいました。

やる時間が全くないわけではないのですが、ゲームなどでリフレッシュしないと育児疲れが厳しいのと、まとまった時間が取りづらいのが理由です。

子どもが起きている間はなかなか PC を広げて作業しづらいですし、寝ている間も夜泣きなどでいつ泣くか分からないので集中して作業ができないです。

とはいえプライベートで開発する時間を取れなくても個人的にはそこまでストレスになっていなくて、今はそういう時期と割り切っています。

また仕事で直接使えるような技術の検証であれば、チームの計画に入れて業務時間内で進められるのでなんとかなっています。

<h2>終わりに</h2>

育休から復帰してまだ半年程度なので育児もまだまだこれからという感じですが、仕事との両立を引き続き頑張っていきたいと思います 💪

ちなみに自分が育休から復帰した前後で他のエンジニアも育休を取得していました。よければこちらの記事もぜひご覧ください！

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fmedia.feedforce.jp%2Fn%2Fn6cf3af35cb86" title="「家庭あっての職業人」限られた時間で成果を出すためにパパエンジニアが取り組んでいること｜フィードフォースのnote" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe>

こんにちは、インフラエンジニアの id:tsub511 です。実は去年の 1 月から 1 年間育休を取っており、今年の 1 月から復帰していました。復帰してから記事を書くのが遅くなってしまいましたが、社内勉強会で話したスライドや育休から復帰してみてどうだったかをまとめてみました。社内勉強会で話した今年の 3 月頃に社内の技術勉強会 FFTT で発表しました。(技術勉強会という立て付けですが、技術に限らず本人が話したいことを話して良い場です)なぜ一年間の育休を取得したのか、育児の知見などがスライド内に書いてありますので気になる方はご覧ください！ちなみに当時のスライド内ではねんねトレーニング (ネントレ) をやっていると書いてありますが、実は現在はやってません。理由はネントレの効果が見られなくなったためです。今年の 4 月くらいから寝付きが悪くなり、胸や背中をトントンしないと寝てくれなくなってしまいました。それ以降夜通し寝てくれないことも増えてしまい、再度ネントレにチャレンジしましたが夜泣きは改善されなかったため、夜泣きの原因は寝かしつけ方法と直接関係ないのでは？と思いネントレをやめました。ちょうどその頃から奥歯が生え始めていたので、それが原因だったのではないかとは思っています。ここ最近は歯の痛みが落ち着いたのか、夜泣きが少し減ってきたような気がします。と思ってたらまた夜泣きが復活しました... 😭やっぱりセルフねんねしてくれてた頃と比べて寝かしつけにかかる時間は増えましたが...寝かしつけで悩んでいる方にとって少しでも参考になれば幸いです。(自分はめっちゃ悩んだ)育休から復帰した感想スライド内でも触れていましたが、やはり一番感じたことは一年間というそれなりに長い期間にも関わらず、普段有給を取るのとそこまで大きく変わらないくらいの感覚でした。もちろん育休を取るという話をしてからチーム内での調整は行いましたが、取得する障壁は特にありませんでした。チームメンバーも育休は取得する前提で育休期間中はどう進めていくのか、という話にフォーカスしている印象でした。そして、一年間の育休を終えて復帰する際にもすんなり業務に戻ることができました。人事やチームメンバーが自分の育休中の変化を事前に記事にまとめてくれていたこともあり、キャッチアップも大体 2 週間くらいで完了しました。復帰がスムーズにいった理由の 1 つにチーム体制や使用技術に大きな変化がなかったことも大きいと思います。以下の記事でも軽く触れていますので良ければご覧ください。働き方の変化育休取得前後 (子どもが生まれる前後) での大きな変化の 1 つとして、働き方がかなり変わりました。子どもが生まれる前は 10:00 ~ 19:00 で働いており、モチベーションや体力がある日は少し長めに働いたり、反対に効率の悪い日は早めに退勤したりという働き方をしていました。子どもが生まれた後は保育園や子どもの就寝時間の都合で 8:00 ~ 17:00 で働くこととなり、保育園の送り迎えや夕飯の支度などがあるので長めに働くということができなくなりました。また、プライベートの時間で技術的な勉強をやることもほとんどなくなってしまいました。やる時間が全くないわけではないのですが、ゲームなどでリフレッシュしないと育児疲れが厳しいのと、まとまった時間が取りづらいのが理由です。子どもが起きている間はなかなか PC を広げて作業しづらいですし、寝ている間も夜泣きなどでいつ泣くか分からないので集中して作業ができないです。とはいえプライベートで開発する時間を取れなくても個人的にはそこまでストレスになっていなくて、今はそういう時期と割り切っています。また仕事で直接使えるような技術の検証であれば、チームの計画に入れて業務時間内で進められるのでなんとかなっています。終わりに育休から復帰してまだ半年程度なので育児もまだまだこれからという感じですが、仕事との両立を引き続き頑張っていきたいと思います 💪ちなみに自分が育休から復帰した前後で他のエンジニアも育休を取得していました。よければこちらの記事もぜひご覧ください！

一年間の育休から復帰しました

こんにちは、<a href="http://blog.hatena.ne.jp/tsub511/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/tsub511/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:tsub511</a> です。

Dockerfile を読みやすくするために <code>\</code> とコメントを駆使してみたら CircleCI で warning が出て一瞬焦ったので記事を書いてみました。

<ul class="table-of-contents">
 <li><a href="#CircleCI-で-docker-build-する時の-warning">CircleCI で docker build する時の warning</a></li>
 <li><a href="#warning-が出たのは-Docker-のバグ">warning が出たのは Docker のバグ</a></li>
 <li><a href="#CircleCI-の-Docker-のデフォルトバージョンは-17090-ce">CircleCI の Docker のデフォルトバージョンは 17.09.0-ce</a></li>
 <li><a href="#まとめ">まとめ</a></li>
</ul>

<h2 id="CircleCI-で-docker-build-する時の-warning">CircleCI で docker build する時の warning</h2>

例えば以下のような Dockerfile があったとします。

<pre class="code lang-dockerfile" data-lang="dockerfile" data-unlink>FROM amazonlinux:2

ENV RUBY_VERSION=2.7.2 \
 BUNDLER_VERSION=2.2.9 \
 TZ=/usr/share/zoneinfo/Asia/Tokyo

RUN \
 # Install mysql-community-devel
 yum install -y yum-utils &amp;&amp; \
 yum localinstall -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm &amp;&amp; \
 yum-config-manager --enable mysql57-community &amp;&amp; \
 yum-config-manager --disable mysql80-community &amp;&amp; \
 yum install -y mysql-community-devel &amp;&amp; \
 yum remove -y mysql80-community-release yum-utils &amp;&amp; \
 \
 # Install ruby
 yum install -y &quot;https://github.com/feedforce/ruby-rpm/releases/download/${RUBY_VERSION}/ruby-${RUBY_VERSION}-1.el7.centos.x86_64.rpm&quot; &amp;&amp; \
 printf &quot;install: --no-document\nupdate: --no-document\n&quot; &gt; /etc/gemrc &amp;&amp; \
 gem install -v &quot;$BUNDLER_VERSION&quot; bundler
</pre>


これを使って CircleCI で docker build すると、<code>Empty continuation lines will become errors in a future release.</code> という warning が出てしまいます。

<figure class="figure-image figure-image-fotolife" title="docker build 時の warning"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20210215/20210215173356.png" alt="f:id:tsub511:20210215173356p:plain" title="" class="hatena-fotolife" itemprop="image"><figcaption>docker build 時の warning</figcaption></figure>

普通に読むと、何もコマンドを実行していない <code>\</code> だけの行やコメントだけの行を消した方が良いのかな？と受け取ってしまいがちですが、これは実は Docker 側のバグでした。

<h2 id="warning-が出たのは-Docker-のバグ">warning が出たのは Docker のバグ</h2>

本来はただの空行だけの場合に warning を出したかったようですが、コメントが書かれた行も warning が出てしまっているようです。

以下に書かれているように、Docker 17.10 で修正済みとのことです。

<blockquote>Thanks for reporting; this issue was resolved through #35004, which is included in Docker 17.10 and up.

I'll close this issue because this was resolved, but feel free to continue the conversation 👍

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fmoby%2Fmoby%2Fissues%2F35387" title="False positive &quot;Empty continuation lines will become errors in a future release.&quot; · Issue #35387 · moby/moby" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/moby/moby/issues/35387">github.com</a></cite></blockquote>

ただ、Docker 17.10 というと 2017/10 リリースのバージョンですので、2021/02 現在でまだバグが残っているのはおかしいです。

CircleCI の Docker のバージョンを確認してみましょう。

<h2 id="CircleCI-の-Docker-のデフォルトバージョンは-17090-ce">CircleCI の Docker のデフォルトバージョンは 17.09.0-ce</h2>

CircleCI 内で docker build を実行するためには <code>setup_remote_docker</code> が必要です。

<code>setup_remote_docker</code> によって CircleCI のジョブのホスト VM で Docker Engine が起動しますが、そこで使われている Docker Engine のバージョンは 17.09.0-ce でした。

<figure class="figure-image figure-image-fotolife" title="CircleCI の Docker Engine バージョン"><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20210215/20210215175709.png" alt="f:id:tsub511:20210215175709p:plain" title="" class="hatena-fotolife" itemprop="image"><figcaption>CircleCI の Docker Engine バージョン</figcaption></figure>

Docker のバグが修正されたのは 17.10 ですので、確かにまだバグが残っているバージョンです。

さて CircleCI の <code>setup_remote_docker</code> ですが、実はデフォルトでは 17.09.0-ce が使われるようです。

<blockquote><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20210215/20210215174427.png" alt="f:id:tsub511:20210215174427p:plain" title="" class="hatena-fotolife" itemprop="image">

<a href="https://circleci.com/docs/2.0/building-docker-images/#docker-version">https://circleci.com/docs/2.0/building-docker-images/#docker-version</a></blockquote>

<h2 id="まとめ">まとめ</h2>

Dockerfile で <code>\</code> だけの行やコメントだけの行がある時に CircleCI で docker build すると <code>Empty continuation lines will become errors in a future release.</code> という warning が出るのは Docker のバグと CircleCI の <code>setup_remote_docker</code> のデフォルトバージョンが古い、という合わせ技によって起きていました。

warning 自体は Docker のバグだったので無視で良いですが、古いバージョンを使い続けるのはあまり良くない気がします。

基本的にはデフォルトを使いたいところですが、17.09.0-ce だと色々な機能が使えないですし、上述したバグもあるので <code>setup_remote_docker</code> を使うときは version を指定することをおすすめします。

こんにちは、id:tsub511 です。Dockerfile を読みやすくするために \ とコメントを駆使してみたら CircleCI で warning が出て一瞬焦ったので記事を書いてみました。CircleCI で docker build する時の warningwarning が出たのは Docker のバグCircleCI の Docker のデフォルトバージョンは 17.09.0-ceまとめCircleCI で docker build する時の warning例えば以下のような Dockerfile があったとします。FROM amazonlinux:2ENV RUBY_VERSION=2.7.2 \    BUNDLER_VERSION=2.2.9 \    TZ=/usr/share/zoneinfo/Asia/TokyoRUN \    # Install mysql-community-devel    yum install -y yum-utils && \    yum localinstall -y https://dev.mysql.com/get/mysql80-community-release-el7-3.noarch.rpm && \    yum-config-manager --enable mysql57-community && \    yum-config-manager --disable mysql80-community && \    yum install -y mysql-community-devel && \    yum remove -y mysql80-community-release yum-utils && \    \    # Install ruby    yum install -y "https://github.com/feedforce/ruby-rpm/releases/download/${RUBY_VERSION}/ruby-${RUBY_VERSION}-1.el7.centos.x86_64.rpm" && \    printf "install: --no-document\nupdate: --no-document\n" > /etc/gemrc && \    gem install -v "$BUNDLER_VERSION" bundlerこれを使って CircleCI で docker build すると、Empty continuation lines will become errors in a future release. という warning が出てしまいます。docker build 時の warning普通に読むと、何もコマンドを実行していない \ だけの行やコメントだけの行を消した方が良いのかな？と受け取ってしまいがちですが、これは実は Docker 側のバグでした。warning が出たのは Docker のバグ本来はただの空行だけの場合に warning を出したかったようですが、コメントが書かれた行も warning が出てしまっているようです。以下に書かれているように、Docker 17.10 で修正済みとのことです。Thanks for reporting; this issue was resolved through #35004, which is included in Docker 17.10 and up.I'll close this issue because this was resolved, but feel free to continue the conversation 👍github.comただ、Docker 17.10 というと 2017/10 リリースのバージョンですので、2021/02 現在でまだバグが残っているのはおかしいです。CircleCI の Docker のバージョンを確認してみましょう。CircleCI の Docker のデフォルトバージョンは 17.09.0-ceCircleCI 内で docker build を実行するためには setup_remote_docker が必要です。setup_remote_docker によって CircleCI のジョブのホスト VM で Docker Engine が起動しますが、そこで使われている Docker Engine のバージョンは 17.09.0-ce でした。CircleCI の Docker Engine バージョンDocker のバグが修正されたのは 17.10 ですので、確かにまだバグが残っているバージョンです。さて CircleCI の setup_remote_docker ですが、実はデフォルトでは 17.09.0-ce が使われるようです。https://circleci.com/docs/2.0/building-docker-images/#docker-versionまとめDockerfile で \ だけの行やコメントだけの行がある時に CircleCI で docker build すると Empty continuation lines will become errors in a future release. という warning が出るのは Docker のバグと CircleCI の setup_remote_docker のデフォルトバージョンが古い、という合わせ技によって起きていました。warning 自体は Docker のバグだったので無視で良いですが、古いバージョンを使い続けるのはあまり良くない気がします。基本的にはデフォルトを使いたいところですが、17.09.0-ce だと色々な機能が使えないですし、上述したバグもあるので setup_remote_docker を使うときは version を指定することをおすすめします。

CircleCI で docker build するときの Empty continuation lines will become errors in a future release. という warning への対処方法

こんにちは、<a href="http://blog.hatena.ne.jp/tsub511/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/tsub511/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:tsub511</a> です。

TELNET プロトコルには全く馴染みがないのですが、今回たまたま使う機会があり、かつ調べても割と見つけられない情報だったので記事を書いてみました。

<ul class="table-of-contents">
 <li><a href="#curl-で-TELNET-プロトコルを使う">curl で TELNET プロトコルを使う</a></li>
 <li><a href="#ユースケース">ユースケース</a></li>
 <li><a href="#解説">解説</a></li>
</ul>

<h2 id="curl-で-TELNET-プロトコルを使う">curl で TELNET プロトコルを使う</h2>

curl は HTTP/HTTPS 以外のプロトコルも使うことができます。

curl のドキュメントを確認すると、サポートしているプロコトルは <code>DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP</code> のようです。

<pre class="code" data-lang="" data-unlink>$ man curl # in macOS

curl(1) Curl Manual curl(1)



NAME
 curl - transfer a URL

SYNOPSIS
 curl [options / URLs]

DESCRIPTION
 curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command
 is designed to work without user interaction.

 curl offers a busload of useful tricks like proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer resume, Metalink, and more. As you will see below, the number of features will make your head spin!

 curl is powered by libcurl for all transfer-related features. See libcurl(3) for details.
...</pre>


例えば以下のように指定することで TELNET プロトコルで対象のサーバーに接続することが可能です。

<pre class="code" data-lang="" data-unlink>$ curl telnet://localhost:3306</pre>


<h2 id="ユースケース">ユースケース</h2>

docker-compose ではコンテナ間の依存関係を <code>depends_on</code> で定義できますが、コンテナ内でサーバーなどが立ち上がるまでは待ってくれません。

そこで、以下のドキュメントに書いてあるような方法でコンテナ間で依存しているサーバーに対するヘルスチェックを行うことで解決できます。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.docker.com%2Fcompose%2Fstartup-order%2F" title="Control startup and shutdown order in Compose" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.docker.com/compose/startup-order/">docs.docker.com</a></cite>

実際には以下のスクリプトで MySQL サーバーの起動を待ってから別のコンテナを実行するような仕組みにしていました。

<pre class="code lang-sh" data-lang="sh" data-unlink>#!/bin/bash

host=&quot;$1&quot;
shift
cmd=&quot;$@&quot;

until mysql -h &quot;$host&quot; -u root -e 'show databases' &gt; /dev/null 2&gt;&amp;1; do
 &gt;&amp;2 echo &quot;MySQL is unavailable - sleeping&quot;
 sleep 1
done

&gt;&amp;2 echo &quot;MySQL is up - executing&quot;
exec $cmd
</pre>


ただ、この方法だと mysql コマンドがコンテナ内にインストールされている必要があります。

本番環境でのコンテナの実行を考慮すると、mysql のクライアントはインストールする必要がなかったので mysql コマンド以外の方法で MySQL サーバーの起動を確認する必要がありました。

そこで、ベースイメージの都合でたまたま curl がインストールされていたので curl の TELNET プロトコルを使うことにしました。

変更後のスクリプトが以下になります。

<pre class="code lang-sh" data-lang="sh" data-unlink>#!/bin/bash

host=&quot;$1&quot;
shift
cmd=&quot;$@&quot;

until echo 'quit' | curl telnet://$host:3306 &gt; /dev/null 2&gt;&amp;1; do
 &gt;&amp;2 echo &quot;MySQL is unavailable - sleeping&quot;
 sleep 1
done

&gt;&amp;2 echo &quot;MySQL is up - executing&quot;
exec $cmd
</pre>


変更したのは 7 行目のみで、mysql コマンドを curl に置き換えています。

こうすることで mysql のクライアントをインストールせずに MySQL サーバーが起動するのを待ってから別のコンテナを実行することができるようになりました。

<h2 id="解説">解説</h2>

例えば以下のように実行すると、TELNET プロトコルを使って疎通確認ができます。

<pre class="code" data-lang="" data-unlink>$ docker run -d -p 3306:3306 -e MYSQL_ALLOW_EMPTY_PASSWORD=1 mysql
$ curl -s -o /dev/null telnet://localhost:3306
</pre>


ただしこのままだと Ctrl+C などでコネクションを切るまで curl が実行されたままになります。

TELNET プロトコルは対話型であるため、コネクションを張りっぱなしになるという認識です。

Ctrl+C が必要ということは、上述したスクリプトでは使えません。

ではどうすれば疎通確認後に自動でコネクションを切れるでしょうか。

実は以下のように <code>quit</code> を curl に標準入力で渡すことで解決できます。

<pre class="code" data-lang="" data-unlink>$ docker run -d -p 3306:3306 -e MYSQL_ALLOW_EMPTY_PASSWORD=1 mysql
$ echo &#39;quit&#39; | curl -s -o /dev/null telnet://localhost:3306</pre>


<code>quit</code> とは何かというと、telnet コマンドでは <code>quit</code> というコマンドを指定することで telnet の接続を切ることができます。

<pre class="code" data-lang="" data-unlink>$ man telnet # in macOS with brew install telnet

TELNET(1) BSD General Commands Manual TELNET(1)

NAME
 telnet -- user interface to the TELNET protocol

SYNOPSIS
 telnet [-468EFKLNacdfruxy] [-S tos] [-X authtype] [-e escapechar] [-k realm] [-l user] [-n tracefile] [-s src_addr] [host [port]]

DESCRIPTION
 The telnet command is used to communicate with another host using the TELNET protocol. If telnet is invoked without the host argument, it enters command mode, indicated by its prompt (``telnet&gt;&#39;&#39;). In this mode, it accepts and executes the commands
 listed below. If it is invoked with arguments, it performs an open command with those arguments.

 Options:

...

quit Close any open TELNET session and exit telnet. An end of file (in command mode) will also close a session and exit.</pre>


そして <code>quit</code> を使った telnet コマンドを自動的に終了するための方法が以下の記事で紹介されていました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fgyoon%2Fitems%2Fdeb7ee62fbe4e9c1a907" title="Telnetの自動化 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/gyoon/items/deb7ee62fbe4e9c1a907">qiita.com</a></cite>

上記の記事を参考に、curl でも同様の方法を試してみたら動いた、ということになります。

ただし、curl に標準入力を渡すことで TELNET プロトコルにコマンドを渡すことができる、という挙動自体は curl のドキュメントを確認しても見つけられませんでした。

公式の情報で裏が取れない限りは当記事の事例のように開発環境でのみ使った方が良いかもしれません。

こんにちは、id:tsub511 です。TELNET プロトコルには全く馴染みがないのですが、今回たまたま使う機会があり、かつ調べても割と見つけられない情報だったので記事を書いてみました。curl で TELNET プロトコルを使うユースケース解説curl で TELNET プロトコルを使うcurl は HTTP/HTTPS 以外のプロトコルも使うことができます。curl のドキュメントを確認すると、サポートしているプロコトルは DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP のようです。$ man curl # in macOScurl(1)                                                                                                                    Curl Manual                                                                                                                    curl(1)NAME       curl - transfer a URLSYNOPSIS       curl [options / URLs]DESCRIPTION       curl is a tool to transfer data from or to a server, using one of the supported protocols (DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP). The command       is designed to work without user interaction.       curl offers a busload of useful tricks like proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer resume, Metalink, and more. As you will see below, the number of features will make your head spin!       curl is powered by libcurl for all transfer-related features. See libcurl(3) for details....例えば以下のように指定することで TELNET プロトコルで対象のサーバーに接続することが可能です。$ curl telnet://localhost:3306ユースケースdocker-compose ではコンテナ間の依存関係を depends_on で定義できますが、コンテナ内でサーバーなどが立ち上がるまでは待ってくれません。そこで、以下のドキュメントに書いてあるような方法でコンテナ間で依存しているサーバーに対するヘルスチェックを行うことで解決できます。docs.docker.com実際には以下のスクリプトで MySQL サーバーの起動を待ってから別のコンテナを実行するような仕組みにしていました。#!/bin/bashhost="$1"shiftcmd="$@"until mysql -h "$host" -u root -e 'show databases' > /dev/null 2>&1; do  >&2 echo "MySQL is unavailable - sleeping"  sleep 1done>&2 echo "MySQL is up - executing"exec $cmdただ、この方法だと mysql コマンドがコンテナ内にインストールされている必要があります。本番環境でのコンテナの実行を考慮すると、mysql のクライアントはインストールする必要がなかったので mysql コマンド以外の方法で MySQL サーバーの起動を確認する必要がありました。そこで、ベースイメージの都合でたまたま curl がインストールされていたので curl の TELNET プロトコルを使うことにしました。変更後のスクリプトが以下になります。#!/bin/bashhost="$1"shiftcmd="$@"until echo 'quit' | curl telnet://$host:3306 > /dev/null 2>&1; do  >&2 echo "MySQL is unavailable - sleeping"  sleep 1done>&2 echo "MySQL is up - executing"exec $cmd変更したのは 7 行目のみで、mysql コマンドを curl に置き換えています。こうすることで mysql のクライアントをインストールせずに MySQL サーバーが起動するのを待ってから別のコンテナを実行することができるようになりました。解説例えば以下のように実行すると、TELNET プロトコルを使って疎通確認ができます。$ docker run -d -p 3306:3306 -e MYSQL_ALLOW_EMPTY_PASSWORD=1 mysql$ curl -s -o /dev/null telnet://localhost:3306ただしこのままだと Ctrl+C などでコネクションを切るまで curl が実行されたままになります。TELNET プロトコルは対話型であるため、コネクションを張りっぱなしになるという認識です。Ctrl+C が必要ということは、上述したスクリプトでは使えません。ではどうすれば疎通確認後に自動でコネクションを切れるでしょうか。実は以下のように quit を curl に標準入力で渡すことで解決できます。$ docker run -d -p 3306:3306 -e MYSQL_ALLOW_EMPTY_PASSWORD=1 mysql$ echo 'quit' | curl -s -o /dev/null telnet://localhost:3306quit とは何かというと、telnet コマンドでは quit というコマンドを指定することで telnet の接続を切ることができます。$ man telnet # in macOS with brew install telnetTELNET(1)                 BSD General Commands Manual                TELNET(1)NAME     telnet -- user interface to the TELNET protocolSYNOPSIS     telnet [-468EFKLNacdfruxy] [-S tos] [-X authtype] [-e escapechar] [-k realm] [-l user] [-n tracefile] [-s src_addr] [host [port]]DESCRIPTION     The telnet command is used to communicate with another host using the TELNET protocol.  If telnet is invoked without the host argument, it enters command mode, indicated by its prompt (``telnet>'').  In this mode, it accepts and executes the commands     listed below.  If it is invoked with arguments, it performs an open command with those arguments.     Options:...quit       Close any open TELNET session and exit telnet.  An end of file (in command mode) will also close a session and exit.そして quit を使った telnet コマンドを自動的に終了するための方法が以下の記事で紹介されていました。qiita.com上記の記事を参考に、curl でも同様の方法を試してみたら動いた、ということになります。ただし、curl に標準入力を渡すことで TELNET プロトコルにコマンドを渡すことができる、という挙動自体は curl のドキュメントを確認しても見つけられませんでした。公式の情報で裏が取れない限りは当記事の事例のように開発環境でのみ使った方が良いかもしれません。

docker-compose での MySQL の疎通確認で telnet を使う時に自動でコネクションを切る

<a href="https://github.com/tsub/alfred-aws-vault-workflow">tsub/alfred-aws-vault-workflow: A Alfred workflow to open the AWS Management Console with aws-vault</a>

Chrome 版

<img src="https://i.gyazo.com/33341687e0419d3863f913a00997744c.gif" alt="Features for Google Chrome" />

Firefox (<a href="https://addons.mozilla.org/firefox/addon/multi-account-containers/">Multi-Account Container</a> extension) 版

<img src="https://i.gyazo.com/a68e0d4cd6f9a80b659cfc1694cd85dd.gif" alt="Features for Firefox" />

aws-vault 自体今回初めて知ったのですが、以下の記事を読んで、複数の AWS アカウント使いには大変便利そうだったので Alfred 用のものをシュッと作りました。

<a href="https://qiita.com/minamijoyo/items/f3cbb003a34954a32970">aws-vault loginでChromeのウィンドウをAWSアカウント毎に分離する - Qiita</a>

tsub/alfred-aws-vault-workflow: A Alfred workflow to open the AWS Management Console with aws-vaultChrome 版Firefox (Multi-Account Container extension) 版aws-vault 自体今回初めて知ったのですが、以下の記事を読んで、複数の AWS アカウント使いには大変便利そうだったので Alfred 用のものをシュッと作りました。aws-vault loginでChromeのウィンドウをAWSアカウント毎に分離する - Qiita

「aws-vault loginでChromeのウィンドウをAWSアカウント毎に分離する」を Alfred 用に作った

こんにちは。インフラエンジニアの id:tsub511 です。私は Dynamoid のメンテナではないのですが、弊社内で今回それなりに大きい問題が起きて、得た知見も大きかったため記事にしました。TL;DRDynamoid にスレッドセーフではない実装があったが PR をマージしてもらって修正済み。2019/08/13 時点ではまだリリースされていないようなので、エラーで困っている方は master ブランチをお使いください。今回起きた問題弊サービスでは Sidekiq 上で Dynamoid を使っています。github.com基本的に問題なく稼働していたのですが、デプロイ時に Sidekiq を再起動した後、Bugsnag に以下のような二種類のエラーが継続的に飛んできました。undefined method `[]' for nil:NilClassundefined method `query' for #<Dynamoid::AdapterPlugin::AwsSdkV3:0x00000000078dc1b8> Did you mean? to_queryこのエラーが起きると、自然には回復しないため、Sidekiq のワーカーを再起動する必要があります。また、NoMethodError という一般的な例外クラスのため ActiveJob の retry_on によるリトライ処理の考慮はしておらず、大事なジョブが実行されないままになってしまうのも問題です。エラーをパッと見ただけでは、キャッシュの実装に考慮漏れがあるのかな？とか、インスタンスが生成されていてコード上ではメソッドが実装されているのになんで undefined method エラーが起きるんだ？などと、不思議なエラーが出ていて調査が難航しそうな印象でした。何が原因だったのかSidekiq + Dynamoid でピンと来る方もいると思いますが、エラーの原因は Dynamoid にスレッドセーフではない実装があったことでした。スレッドセーフではない実装がどこにあったのか探すために、ここで発生していたエラーをもう一度見てみます。' for nil:NilClass">undefined method `' for nil:NilClassまず 1 つ目のエラーは nil に対して #[] を呼び出そうとしてエラーになっていますが、nil になっている変数は table_cache です。table_cache は以下で初期化されています。# https://github.com/Dynamoid/dynamoid/blob/v3.2.0/lib/dynamoid/adapter_plugin/aws_sdk_v3.rb#L66-L69def connect! @client = Aws::DynamoDB::Client.new(connection_config) @table_cache = {}endそして、この初期化のための Dynamoid::AdapterPlugin::AwsSdkV3#connect! を呼び出しているのは Dynamoid::Adapter#adapter です。adapter.connect! の部分に if adapter.respond_to?(:connect!) という条件がありますが、ここが false になっていて adapter.connect! が実行されていないため、table_cache の初期化処理が動いていないようです。# https://github.com/Dynamoid/dynamoid/blob/v3.2.0/lib/dynamoid/adapter.rb#L29-L37def adapter unless @adapter_.value adapter = self.class.adapter_plugin_class.new adapter.connect! if adapter.respond_to?(:connect!) @adapter_.compare_and_set(nil, adapter) clear_cache! end @adapter_.valueend2 つ目のエラーも見てみます。undefined method `query' for #<Dynamoid::AdapterPlugin::AwsSdkV3:0x00000000078dc1b8> Did you mean? to_queryこちらは Dynamoid::AdapterPlugin::AwsSdkV3 のインスタンス adapter に対して query を実行しようとしてメソッドが定義されていないというエラーです。しかし、実際のコードにはメソッドが定義されています。https://github.com/Dynamoid/dynamoid/blob/v3.2.0/lib/dynamoid/adapter_plugin/aws_sdk_v3.rb#L489-L500 def query(table_name, options = {}) Enumerator.new do |yielder| table = describe_table(table_name) Query.new(client, table, options).call.each do |page| yielder.yield( page.items.map { |row| result_item_to_hash(row) }, last_evaluated_key: page.last_evaluated_key ) end end end視点を変えて、adapter インスタンスを定義しているコードを見てみると、やはり Dynamoid::Adapter#adapter に行き着きます。# https://github.com/Dynamoid/dynamoid/blob/v3.2.0/lib/dynamoid/adapter.rb#L29-L37def adapter unless @adapter_.value adapter = self.class.adapter_plugin_class.new adapter.connect! if adapter.respond_to?(:connect!) @adapter_.compare_and_set(nil, adapter) clear_cache! end @adapter_.valueendself.class.adapter_plugin_class.new で生成したものをメモ化しています。メモ化には concurrent-ruby を使っていて、過去に対策されたようなのでそこは問題なさそうです。self.class.adapter_plugin_class.new の先が怪しそうなのでコードを見てみると、なにやら動的に require しています。# https://github.com/Dynamoid/dynamoid/blob/v3.2.0/lib/dynamoid/adapter.rb#L181-L187def self.adapter_plugin_class unless Dynamoid.const_defined?(:AdapterPlugin) && Dynamoid::AdapterPlugin.const_defined?(Dynamoid::Config.adapter.camelcase) require "dynamoid/adapter_plugin/#{Dynamoid::Config.adapter}" end Dynamoid::AdapterPlugin.const_get(Dynamoid::Config.adapter.camelcase)end実はスレッドセーフではない実装はこの require する条件の Dynamoid.const_defined?(:AdapterPlugin) && Dynamoid::AdapterPlugin.const_defined?(Dynamoid::Config.adapter.camelcase) の部分です。エラーを再現できるコードを Gist に用意しましたのでそちらを使って確認していきます。Test codes to reproduce not thread-safe errors of Dynamoid · GitHubDynamoid に以下のような変更を加えて、unless の中に入らず require が実行されなかった時の状態を見てみます。diff --git a/lib/dynamoid/adapter.rb b/lib/dynamoid/adapter.rbindex f390ecf..df2a58c 100644--- a/lib/dynamoid/adapter.rb+++ b/lib/dynamoid/adapter.rb@@ -181,6 +181,13 @@ module Dynamoid def self.adapter_plugin_class unless Dynamoid.const_defined?(:AdapterPlugin) && Dynamoid::AdapterPlugin.const_defined?(Dynamoid::Config.adapter.camelcase) require "dynamoid/adapter_plugin/#{Dynamoid::Config.adapter}"+ else+ tmp_adapter = Dynamoid::AdapterPlugin.const_get(Dynamoid::Config.adapter.camelcase).new+ puts <<~EOS+ respond_to?(:connect!): #{tmp_adapter.respond_to?(:connect!)},+ respond_to?(:query): #{tmp_adapter.respond_to?(:query)},+ require: #{require "dynamoid/adapter_plugin/#{Dynamoid::Config.adapter}"}+ EOS end Dynamoid::AdapterPlugin.const_get(Dynamoid::Config.adapter.camelcase)すると、スレッドによっては const_defined? の結果が true で、require の結果も false (コードがロード済み) なのに、実際のメソッドが存在しないという現象が起きていることが分かりました。$ bundle exec ruby main.rb...respond_to?(:connect!): false,respond_to?(:query): false,require: false...ここからは Ruby の require の実装を知らないため推測になります。おそらくマルチスレッド環境下で require を実行すると、require を実行したスレッド内では全てのコードがロードされた状態になりますが、別のスレッドではクラス定義などの「ガワ」だけがロードされた状態になっているのではないかと思いました。そのため、ロードが不十分なスレッドでインスタンスを生成できるが、メソッドが定義されていない、という状態になっているのかと思われます。解決方法よって、全てのスレッドで確実に require を実行することで今回のエラーが解決するという結論に至りました。diff --git a/lib/dynamoid/adapter.rb b/lib/dynamoid/adapter.rbindex f390ecf..8449e34 100644--- a/lib/dynamoid/adapter.rb+++ b/lib/dynamoid/adapter.rb@@ -179,9 +179,7 @@ module Dynamoid end def self.adapter_plugin_class- unless Dynamoid.const_defined?(:AdapterPlugin) && Dynamoid::AdapterPlugin.const_defined?(Dynamoid::Config.adapter.camelcase)- require "dynamoid/adapter_plugin/#{Dynamoid::Config.adapter}"- end+ require "dynamoid/adapter_plugin/#{Dynamoid::Config.adapter}" Dynamoid::AdapterPlugin.const_get(Dynamoid::Config.adapter.camelcase) endエラーの原因と解決方法が判明したため、既に Dynamoid に PR を作りマージまでしてもらいました。github.com2019/08/13 時点ではまだリリースされていないようなので、エラーで困っている方は master ブランチをお使いください。調査に苦労した点マルチスレッドプログラミングの経験が浅いため、まずスレッドセーフではない実装があるということに気づくまでに時間がかかりました。そして、エラーを再現しようとした時になかなか再現出来なかったのもハマりポイントでした。エラーの再現コードを読むと分かりますが、Dynamoid のメソッドを呼ぶ直前に puts を実行しています。# https://gist.github.com/tsub/72e60233ed82a8a453428ea7441e6017#file-main-rb100.times do |i| safe_thread(i.to_s) do puts 'debug' # To unlock Ruby's GVL Document.where(identifier: 'hoge').first endendこの puts が重要で、Ruby は GVL (Giant VM Lock) という仕組みを使って、実行されるネイティブスレッドが 1 つになるように排他制御をしています。ただし、IO 関連のメソッドを実行する際は GVL が一時的に解放されてスレッドが同時に実行されます。ネイティブスレッドを用いて実装されていますが、 現在の実装では Ruby VM は Giant VM lock (GVL) を有しており、同時に実行される ネイティブスレッドは常にひとつです。 ただし、IO 関連のブロックする可能性があるシステムコールを行う場合には GVL を解放します。その場合にはスレッドは同時に実行され得ます。 また拡張ライブラリから GVL を操作できるので、複数のスレッドを 同時に実行するような拡張ライブラリは作成可能です。docs.ruby-lang.orgつまりスレッドセーフではない実装があった場合に、それを再現させるためには単純にスレッドセーフではないコードを書くだけではダメで、IO 関連のメソッドを実行して GVL を解放しないといけません。少し古い記事ではありますが、こちらが参考になりました。moyomot.hatenablog.com実際の本番環境ではログ出力などにより、IO 関連のメソッドは普通に実行されていることが多いかと思いますので、エラーが起きるのも納得です。

 Dynamoid のスレッドセーフではない実装を直しました

とうとう待望の CircleCI Orbs がリリースされたので一通り触ってみました。

<a href="https://circleci.com/blog/announcing-orbs-technology-partner-program/">Announcing CircleCI Orbs and our new Technology Partner Program</a>

今回作ったサンプルは以下のリポジトリにありますので手っ取り早く知りたい人は以下のコードを見ると良いかと思います。

 <a href="https://github.com/tsub/circleci-orbs-sandbox">tsub/circleci-orbs-sandbox</a>

とうとう待望の CircleCI Orbs がリリースされたので一通り触ってみました。Announcing CircleCI Orbs and our new Technology Partner Program今回作ったサンプルは以下のリポジトリにありますので手っ取り早く知りたい人は以下のコードを見ると良いかと思います。 tsub/circleci-orbs-sandbox

CircleCI Orbs 入門

先日プライベートの開発マシンを Linux にしたのですが、macOS の時に一番重宝していたものがなにかというと、実は <a href="https://www.alfredapp.com/">Alfred</a> だったことに気づきました。

Alfred がないとストレスフルです。

ただ Linux には Alternative Alfred がいくつかあり、その中でも Albert が比較的良さそうだったので Albert を使っていますが、Alfred で言う Workflow にあたるものが全然充実していませんでした。

特に Alfred から GitHub を開く操作が一番多い気がするので、まずはそれを Albert でもできるようにするために、今回拡張を作りました。

 <a href="https://github.com/tsub/albert-github">tsub/albert-github: Open GitHub repository in browser with Albert</a>

<img src="https://gyazo.com/fff7125ea22e33c863f6fd535d7f2b8b.png" alt="image" />

先日プライベートの開発マシンを Linux にしたのですが、macOS の時に一番重宝していたものがなにかというと、実は Alfred だったことに気づきました。Alfred がないとストレスフルです。ただ Linux には Alternative Alfred がいくつかあり、その中でも Albert が比較的良さそうだったので Albert を使っていますが、Alfred で言う Workflow にあたるものが全然充実していませんでした。特に Alfred から GitHub を開く操作が一番多い気がするので、まずはそれを Albert でもできるようにするために、今回拡張を作りました。 tsub/albert-github: Open GitHub repository in browser with Albert

Albert で GitHub リポジトリを開ける拡張を作った

<a href="https://github.com/tsub/s3-edit">個人プロジェクト</a>にて、先日リリースされた Go 1.11 の Modules (vgo) を使ってみました。

移行自体はスムーズにできたのですが、CircleCI でのキャッシュのやり方がそこそこ重要かも？と思ったので記事を書きました。

個人プロジェクトにて、先日リリースされた Go 1.11 の Modules (vgo) を使ってみました。移行自体はスムーズにできたのですが、CircleCI でのキャッシュのやり方がそこそこ重要かも？と思ったので記事を書きました。

Go 1.11 の Modules (vgo) を CircleCI で使う

こんにちは、エンジニアの <a href="http://blog.hatena.ne.jp/tsub511/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/tsub511/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:tsub511</a> です。

先日 Kubernetes.rb という勉強会があり、そちらの講師役として参加してきました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flocalhost.connpass.com%2Fevent%2F90340%2F" title="Kubernetes.rb (2018/07/21 13:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://localhost.connpass.com/event/90340/">localhost.connpass.com</a></cite>

<code>.rb</code> と言いつつ Ruby の話は一切ありませんでした。タイトルの伏線は回収されず 😁

<h2>参加の経緯</h2>

さて、今回自分としては初の勉強会の主催側 (?) としてお手伝いすることとなったのですが、その経緯について軽くご紹介します。

もともと一からイベントを企画したわけではなく、主催の <a href="https://twitter.com/yoshi_hirano">@yoshi_hirano</a> さんが講師役を募集していたところに応募した形になります。

ただ、応募の経緯としては先日ご退職された元フィードフォースの <a href="https://twitter.com/284km">@284km</a> さんから、「講師役やってくれる人を1名探しているんですが、tsub 氏どうですか？」というお誘いを貰い、やってみたいと思ったので繋いでいただいた感じです。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20180723/20180723125903.png" alt="f:id:tsub511:20180723125903p:plain" title="f:id:tsub511:20180723125903p:plain" class="hatena-fotolife" itemprop="image">
ちなみに社内で Kubernetes について勉強していくぞ！！的なチャンネルが最近できました。

<h2>実際の準備</h2>

やると決まってからは当日まで 1 ヶ月半ぐらいあったのですが、そこからは Twitter でグループ DM しながら準備を進めていきました。

とはいえ、お互い顔も分からず会ったことのない中で Twitter の DM オンリーで準備を進めていったので少々不安を感じながらも、<a href="https://twitter.com/yoshi_hirano">@yoshi_hirano</a> さんやサポート役の <a href="https://twitter.com/katsuhisa__">@katsuhisa__</a> さんから優しくして頂けたので問題なく進められました。

準備に際しては以下のリポジトリのコミット権を貰い、そこにサンプルを自分が足していきました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Flocalhost9292%2Fkubernetes.rb" title="localhost9292/kubernetes.rb" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/localhost9292/kubernetes.rb">github.com</a></cite>

また、Rails のサンプルアプリについては以下のリポジトリも用意してもらいました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fyhirano55%2Freact-redux-jwt-authentication-example" title="yhirano55/react-redux-jwt-authentication-example" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/yhirano55/react-redux-jwt-authentication-example">github.com</a></cite>

あとは当日までひたすら YAML を書く... 😇 という感じになります。

最初に作った Rails 用の YAML には結構時間がかかったものの、残りのアプリはほとんどコピペでサクサク進んでいきました。

ただ、Sentry などは自分で動かしたことがなかったので、Kubernetes で動かすというよりはアプリそのもののセットアップ手順や構成などを理解するのに時間がかかったように思います。

また、Discourse と GitLab については Docker イメージの使い方が独特で、<a href="https://github.com/discourse/discourse_docker">Discourse</a> の方は独自のシェルスクリプトを使っていて読み解くのがが大変そうで、<a href="https://hub.docker.com/r/gitlab/gitlab-ce/">GitLab</a> の方はコンテナを動かしたら Chef が動き始めて色々インストールしだしたので諦めました。

代わりに Mastodon を動かすことになりました。動かし始めたらいけそうだったので、勢いで当日の朝も準備をしてました..

<h2>勉強会当日の様子</h2>

会場は<a href="https://everyleaf.com/">株式会社万葉</a>さんのオフィスをお借りしました (自分がその辺りを手配したわけではないです)。

とても快適でした。万葉さんありがとうございました 🤗

特に、Chrome Cast に繋がったプロジェクターが設置してあり、各自何か言いたいことがある時にサクッと画面共有できて良かったかと思います。

全体としては 12:30 ぐらいからゆるっと始まり、17:30 ぐらいに解散しました。

最初に <a href="https://twitter.com/yoshi_hirano">@yoshi_hirano</a> さんから流れの説明があり、各自簡単に自己紹介をした後はそれぞれ<a href="https://github.com/localhost9292/kubernetes.rb">資料</a>を見ながらもくもくやっていました。

ただ、最初に Minikube で躓く人が多かったようです。

以下の Issue を参考に、最終的に <code>$ minikube start --vm-driver=hyperkit --bootstrapper=localkube</code> で動いたようです。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fkubernetes%2Fminikube%2Fissues%2F2765" title="minikube start hangs forever on mac · Issue #2765 · kubernetes/minikube" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/kubernetes/minikube/issues/2765">github.com</a></cite>

ちなみに自分は <code>$ minikube start --vm-driver=hyperkit</code> だけで動きました。

Minikube が動かないので GKE で進める方も多かったようです (サンプルは Minikube と GKE 両方の手順を用意していました)。

後は、イメージの Pull や DB のマイグレーションジョブの実行など、待ち時間が多かったためか、それなりにわいわい話しながら皆で進めてました。

自分は講師役という立ち位置でしたが、感覚的にはどちらかというと大学の講義で手伝いをしていた感じです。

質問があったら近くに行って答えるのを繰り返しつつ、何もない時は Mastodon の GKE 版のサンプル資料を作っていました。

最終的には Mastodon まで動かせた方も多く、サンプルを用意した自分としては非常に嬉しかったです ✨

また、最後に KPT 方式の振り返りをやったのですが、Trello を使ったやり方が個人的にはすごく良かったです。

会社でもやってみたいなと思いました。

振り返りの様子。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20180723/20180723125937.png" alt="f:id:tsub511:20180723125937p:plain" title="f:id:tsub511:20180723125937p:plain" class="hatena-fotolife" itemprop="image">

なお、どうやら弊社で月一でやっているもくもく会がたまたま同日開催で場所も<a href="https://basispoint.tokyo/coworking/jimbocho/">神保町</a>と、会場のすぐ側でやっていたようです。

<a href="http://blog.hatena.ne.jp/masutaka26/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/masutaka26/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:masutaka26</a> がひっそりとリモートで参加していました 😎

<blockquote class="twitter-tweet" data-lang="ja">02_nginx でこんなエラーが出た <a href="https://twitter.com/hashtag/localhost9292?src=hash&amp;ref_src=twsrc%5Etfw">#localhost9292</a> $ kubectl apply -f k8s/deployment.yaml Error from server (BadRequest): error when creating &quot;k8s/deployment.yaml&quot;: Deployment in version &quot;v1&quot; cannot be handled as a Deployment: no kind &quot;Deployment&quot; is registered for version &quot;apps/v1&quot;&mdash; Takashi Masuda (@masutaka) <a href="https://twitter.com/masutaka/status/1020547692378783744?ref_src=twsrc%5Etfw">2018年7月21日</a></blockquote>


<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>




<blockquote class="twitter-tweet" data-conversation="none" data-lang="ja">minikube のアップデートで直った！&mdash; Takashi Masuda (@masutaka) <a href="https://twitter.com/masutaka/status/1020553958337605634?ref_src=twsrc%5Etfw">2018年7月21日</a></blockquote>


<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


<h2>資料の補足</h2>

KPT の P にも上がっていましたが、途中実行待ちが長いときに「これは上手くいっていて単純に時間のかかる処理なのか、そもそも上手く動いていないのか」というお声を頂きました。

それについてはログを見る方法についても明示しておけば良かったと思っています。

Kubernetes でログを見るには <code>$ kubectl logs</code> コマンドを使います。

<pre class="code" data-lang="" data-unlink>$ kubectl logs -f &lt;Pod Name&gt;</pre>


(<code>tail</code> と同じように <code>-f</code> でストリーミングができます)

Job の実行時などにはログを見ながら今何が動いているのかを見るとより分かりやすかったと思います。

また、今回は Pod, Deployment, Service などの概念についての説明をせずにとりあえず手を動かしてみるという会でしたが、その辺りについては Kubernetes.rb #2 が開催されるようなので、興味のある方はぜひご参加ください！ (自分は次回は参加しないですが 🙇)

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Flocalhost.connpass.com%2Fevent%2F95578%2F" title="Kubernetes.rb #2 (2018/09/01 11:00〜)" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://localhost.connpass.com/event/95578/">localhost.connpass.com</a></cite>

<h2>やってみた感想など</h2>

今回初めて勉強会の主催側として参加したわけですが、感想としてはやって良かった！！と思っています。

そもそも Kubernetes についてはまだ仕事で使っているわけでもなく導入の検討段階ですし、個人で趣味レベルで動かした程度だったので今回の資料作成の中でかなり理解が深まったと思っています。

また、メンタル的にも成長できた気がします。

会ったことのない社外の人たちがいる場に飛び込むのは個人的にはなかなかハードルが高く、今まで勉強会に参加する際は懇親会にはあまり出ないタイプだったのですが、今回の体験で「あ、なんだ。こんな感じなのか」みたいな感覚を得られたので今後は懇親会などに参加して社外の人とも交流する勇気が少し出ました。

それでは最後に改めて、<a href="https://twitter.com/yoshi_hirano">@yoshi_hirano</a> さんや <a href="https://twitter.com/katsuhisa__">@katsuhisa__</a> さん、会場を提供してくださった万葉さん、参加してくださった皆様、ありがとうございました 👋

こんにちは、エンジニアの id:tsub511 です。先日 Kubernetes.rb という勉強会があり、そちらの講師役として参加してきました。localhost.connpass.com.rb と言いつつ Ruby の話は一切ありませんでした。タイトルの伏線は回収されず 😁参加の経緯さて、今回自分としては初の勉強会の主催側 (?) としてお手伝いすることとなったのですが、その経緯について軽くご紹介します。もともと一からイベントを企画したわけではなく、主催の @yoshi_hirano さんが講師役を募集していたところに応募した形になります。ただ、応募の経緯としては先日ご退職された元フィードフォースの @284km さんから、「講師役やってくれる人を1名探しているんですが、tsub 氏どうですか？」というお誘いを貰い、やってみたいと思ったので繋いでいただいた感じです。ちなみに社内で Kubernetes について勉強していくぞ！！的なチャンネルが最近できました。実際の準備やると決まってからは当日まで 1 ヶ月半ぐらいあったのですが、そこからは Twitter でグループ DM しながら準備を進めていきました。とはいえ、お互い顔も分からず会ったことのない中で Twitter の DM オンリーで準備を進めていったので少々不安を感じながらも、@yoshi_hirano さんやサポート役の @katsuhisa__ さんから優しくして頂けたので問題なく進められました。準備に際しては以下のリポジトリのコミット権を貰い、そこにサンプルを自分が足していきました。github.comまた、Rails のサンプルアプリについては以下のリポジトリも用意してもらいました。github.comあとは当日までひたすら YAML を書く... 😇 という感じになります。最初に作った Rails 用の YAML には結構時間がかかったものの、残りのアプリはほとんどコピペでサクサク進んでいきました。ただ、Sentry などは自分で動かしたことがなかったので、Kubernetes で動かすというよりはアプリそのもののセットアップ手順や構成などを理解するのに時間がかかったように思います。また、Discourse と GitLab については Docker イメージの使い方が独特で、Discourse の方は独自のシェルスクリプトを使っていて読み解くのがが大変そうで、GitLab の方はコンテナを動かしたら Chef が動き始めて色々インストールしだしたので諦めました。代わりに Mastodon を動かすことになりました。動かし始めたらいけそうだったので、勢いで当日の朝も準備をしてました..勉強会当日の様子会場は株式会社万葉さんのオフィスをお借りしました (自分がその辺りを手配したわけではないです)。とても快適でした。万葉さんありがとうございました 🤗特に、Chrome Cast に繋がったプロジェクターが設置してあり、各自何か言いたいことがある時にサクッと画面共有できて良かったかと思います。全体としては 12:30 ぐらいからゆるっと始まり、17:30 ぐらいに解散しました。最初に @yoshi_hirano さんから流れの説明があり、各自簡単に自己紹介をした後はそれぞれ資料を見ながらもくもくやっていました。ただ、最初に Minikube で躓く人が多かったようです。以下の Issue を参考に、最終的に $ minikube start --vm-driver=hyperkit --bootstrapper=localkube で動いたようです。github.comちなみに自分は $ minikube start --vm-driver=hyperkit だけで動きました。Minikube が動かないので GKE で進める方も多かったようです (サンプルは Minikube と GKE 両方の手順を用意していました)。後は、イメージの Pull や DB のマイグレーションジョブの実行など、待ち時間が多かったためか、それなりにわいわい話しながら皆で進めてました。自分は講師役という立ち位置でしたが、感覚的にはどちらかというと大学の講義で手伝いをしていた感じです。質問があったら近くに行って答えるのを繰り返しつつ、何もない時は Mastodon の GKE 版のサンプル資料を作っていました。最終的には Mastodon まで動かせた方も多く、サンプルを用意した自分としては非常に嬉しかったです ✨また、最後に KPT 方式の振り返りをやったのですが、Trello を使ったやり方が個人的にはすごく良かったです。会社でもやってみたいなと思いました。振り返りの様子。なお、どうやら弊社で月一でやっているもくもく会がたまたま同日開催で場所も神保町と、会場のすぐ側でやっていたようです。id:masutaka26 がひっそりとリモートで参加していました 😎02_nginx でこんなエラーが出た #localhost9292$ kubectl apply -f k8s/deployment.yamlError from server (BadRequest): error when creating "k8s/deployment.yaml": Deployment in version "v1" cannot be handled as a Deployment: no kind "Deployment" is registered for version "apps/v1"— Takashi Masuda (@masutaka) 2018年7月21日minikube のアップデートで直った！— Takashi Masuda (@masutaka) 2018年7月21日資料の補足KPT の P にも上がっていましたが、途中実行待ちが長いときに「これは上手くいっていて単純に時間のかかる処理なのか、そもそも上手く動いていないのか」というお声を頂きました。それについてはログを見る方法についても明示しておけば良かったと思っています。Kubernetes でログを見るには $ kubectl logs コマンドを使います。$ kubectl logs -f <Pod Name>(tail と同じように -f でストリーミングができます)Job の実行時などにはログを見ながら今何が動いているのかを見るとより分かりやすかったと思います。また、今回は Pod, Deployment, Service などの概念についての説明をせずにとりあえず手を動かしてみるという会でしたが、その辺りについては Kubernetes.rb #2 が開催されるようなので、興味のある方はぜひご参加ください！ (自分は次回は参加しないですが 🙇)localhost.connpass.comやってみた感想など今回初めて勉強会の主催側として参加したわけですが、感想としてはやって良かった！！と思っています。そもそも Kubernetes についてはまだ仕事で使っているわけでもなく導入の検討段階ですし、個人で趣味レベルで動かした程度だったので今回の資料作成の中でかなり理解が深まったと思っています。また、メンタル的にも成長できた気がします。会ったことのない社外の人たちがいる場に飛び込むのは個人的にはなかなかハードルが高く、今まで勉強会に参加する際は懇親会にはあまり出ないタイプだったのですが、今回の体験で「あ、なんだ。こんな感じなのか」みたいな感覚を得られたので今後は懇親会などに参加して社外の人とも交流する勇気が少し出ました。それでは最後に改めて、@yoshi_hirano さんや @katsuhisa__ さん、会場を提供してくださった万葉さん、参加してくださった皆様、ありがとうございました 👋

Kubernetes.rb に講師役として参加してきました

こんにちは、エンジニアの <a href="http://blog.hatena.ne.jp/tsub511/" class="hatena-id-icon"><img src="https://cdn.profile-image.st-hatena.com/users/tsub511/profile.png" width="16" height="16" alt="" class="hatena-id-icon">id:tsub511</a> です。
ここ数日気温の寒暖差が凄いですね。昨日あまりにも寒すぎて一度しまった冬用の布団を引っ張りだしたら、また気温が上がってきたので片付けることになりそうです。

最近、Datadog でプロセスがオープンしているファイルディスクリプタ数のメトリクスを取る必要があり、色々と考えた結果良い方法を思いついたため、今回ご紹介します。

<h2>Datadog 標準の <code>system.processes.open_file_descriptors</code> メトリクスを取るには root 権限が必要</h2>

Datadog では標準で、Process Check という機能を使うことで <code>system.processes.open_file_descriptors</code> メトリクスを取ることができます。

<blockquote><img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20180511/20180511150551.png" alt="f:id:tsub511:20180511150551p:plain" title="f:id:tsub511:20180511150551p:plain" class="hatena-fotolife" itemprop="image">

<a href="https://docs.datadoghq.com/integrations/process/#metrics">https://docs.datadoghq.com/integrations/process/#metrics</a></blockquote>

ただし、説明文にも書いてある通り <code>dd-agent</code> ユーザーが実行したプロセスしかこのメトリクスを取得することが出来ません。

そのため、例えば Rails アプリケーションを動かすために <code>puma</code> プロセスを <code>dev</code> ユーザーで動かしていた場合、以下のような設定を書いても <code>system.processes.open_file_descriptors</code> メトリクスを取得することが出来ません。

<pre class="code" data-lang="" data-unlink>init_config:

instances:
 - name: puma_worker
 search_string: [&#34;puma: cluster worker&#34;]
 exact_match: False</pre>


<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/tsub511/20180511/20180511151024.png" alt="f:id:tsub511:20180511151024p:plain" title="f:id:tsub511:20180511151024p:plain" class="hatena-fotolife" itemprop="image">

これは何故かというと、プロセスがオープンしているファイルディスクリプタ数を取得するためには <code>/proc/&lt;PID&gt;/fd</code> 以下にアクセスする必要があるためです。

<code>/proc/&lt;PID&gt;/fd</code> ディレクトリはそのプロセスを実行したユーザーにしか read 権限がありません。

<pre class="code" data-lang="" data-unlink>$ ls -al /proc/1/fd
ls: cannot open directory /proc/1/fd: Permission denied

$ sudo ls -al /proc/1 | grep fd
dr-x------. 2 root root 0 Apr 18 06:58 fd
dr-x------. 2 root root 0 May 11 06:12 fdinfo</pre>


そのため、<code>dd-agent</code> はそのメトリクスを取得できないというわけです。

ただし、<code>dd-agent</code> に root 権限を与えることで、閲覧は可能になります。
公式ドキュメントではそのやり方が提示されていますが、セキュリティ的にリスクがあるため、推奨はされていません。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.datadoghq.com%2Fagent%2Ffaq%2Fwhy-don-t-i-see-the-system-processes-open-file-descriptors-metric" title="Why don&#39;t I see the &#39;system.processes.open_file_descriptors&#39; metric?" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.datadoghq.com/agent/faq/why-don-t-i-see-the-system-processes-open-file-descriptors-metric">docs.datadoghq.com</a></cite>

さて、この記事の内容は <code>dd-agent</code> に root 権限を与えずに <code>system.processes.open_file_descriptors</code> メトリクスを取得するということでしたが、どうやれば良いのでしょう？

<h2>DogStatsD を使う</h2>

Datadog には DogStatsD という仕組みがあります。

DogStatsD は任意のカスタムメトリクスを Datadog に送る方法の一つです。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.datadoghq.com%2Fdevelopers%2Fdogstatsd%2F" title="DogStatsD" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.datadoghq.com/developers/dogstatsd/">docs.datadoghq.com</a></cite>

通常は以下のような言語毎のライブラリを公式が提供してくれているため、こちらを使うことで任意のカスタムメトリクスを送ることができます。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2FDataDog%2Fdatadog-go" title="DataDog/datadog-go" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/DataDog/datadog-go">github.com</a></cite>

DogStatsD を通してメトリクスを送る際は、その送り側のプロセスは任意のユーザーで実行できます。

そのため、上記の例にあったように <code>dev</code> ユーザーが <code>puma</code> プロセスを実行している場合は <code>dev</code> ユーザーで DogStatsD にメトリクスを送るプロセスを実行すれば、
同じ <code>dev</code> ユーザーのため <code>/proc/&lt;PID&gt;/fd</code> への read 権限があります。

思いついてみれば簡単なことでしたね。

<h2>でもプログラミング言語で実装するのは面倒じゃない？</h2>

少し本題とは反れますが、もう少しお手軽に DogStatsD にカスタムメトリクスを送りたいな、とも思います。

そこで、調べてみたところ「DogStatsD には単純に専用のフォーマットで UDP パケットを送るだけで良い」ということを知りました。

<blockquote>On Linux:

<code>
vagrant@vagrant-ubuntu-14-04:~$ echo -n "custom_metric:60|g|#shell" &gt;/dev/udp/localhost/8125
</code>

or

<code>
vagrant@vagrant-ubuntu-14-04:~$ echo -n "custom_metric:60|g|#shell" | nc -4u -w0 127.0.0.1 8125
</code>

<a href="https://docs.datadoghq.com/developers/dogstatsd/#sending-metrics">https://docs.datadoghq.com/developers/dogstatsd/#sending-metrics</a></blockquote>

上記のように、DogStatsD のエンドポイントである <code>localhost:8125</code> に <code>custom_metric:60|g|#shell</code> のようなフォーマットで UDP パケットを送ってやれば良いです。

そのため、プロセスがオープンしているファイルディスクリプタ数のカスタムメトリクスを送るには、以下のコマンドを実行すれば良いです。

<pre class="code" data-lang="" data-unlink>$ echo -n &#34;open_file_descriptors.puma_worker:$(ls /proc/$(pgrep -f -u dev &#39;puma: cluster worker&#39; | head -1)/fd/ | wc -l):g&#34; | nc -u -4 localhost 8125</pre>


上記のコマンドを <code>crontab</code> などで毎分実行してやれば <code>open_file_descriptors.puma_worker</code> メトリクスを送ることができます。

ただし、実際に本番で利用しているコマンドはそこまで単純ではなく、以下のようなシェルスクリプトを書いて実行しています。

<pre class="code lang-sh" data-lang="sh" data-unlink>#!/bin/sh

if [ $# -ne 2 ]; then
 echo &quot;Require 2 arguments&quot; 1&gt;&amp;2
 exit 1
fi

PROCESS_NAME=$1
USER=$2

# pgrep でシェルスクリプト自身のプロセスがマッチしてしまうため `grep -v` で除外する
# CentOS 6 では pgrep に -a オプションがないため注意
#
# 複数のプロセスが見つかっても無視する
PROCESS=$(pgrep -f -a -u &quot;${USER}&quot; &quot;${PROCESS_NAME}&quot; | grep -v &quot;$0&quot; | head -1 | cut -f 1 -d ' ')

if [ -z &quot;${PROCESS}&quot; ]; then
 echo &quot;${PROCESS_NAME} does not exists&quot; 1&gt;&amp;2
 exit 1
fi

ls /proc/&quot;${PROCESS}&quot;/fd/ | wc -l
</pre>




<pre class="code lang-sh" data-lang="sh" data-unlink>#!/bin/bash

if [ $# -ne 3 ]; then
 echo &quot;Require 3 arguments&quot; 1&gt;&amp;2
 exit 1
fi

METRIC_NAME=$1
VARUE=$2
METRIC_TYPE=$3

echo -n &quot;${METRIC_NAME}:${VARUE}|${METRIC_TYPE}&quot; | nc -u -4 localhost 8125
</pre>




<pre class="code" data-lang="" data-unlink>$ crontab -l
* * * * * /path/to/send-to-dogstatsd.sh open_file_descriptors.puma_cluster_worker $(/path/to/get-open-fd.sh &#34;puma: cluster worker&#34; dev) g &gt; /dev/null</pre>

こんにちは、エンジニアの id:tsub511 です。ここ数日気温の寒暖差が凄いですね。昨日あまりにも寒すぎて一度しまった冬用の布団を引っ張りだしたら、また気温が上がってきたので片付けることになりそうです。最近、Datadog でプロセスがオープンしているファイルディスクリプタ数のメトリクスを取る必要があり、色々と考えた結果良い方法を思いついたため、今回ご紹介します。Datadog 標準の system.processes.open_file_descriptors メトリクスを取るには root 権限が必要Datadog では標準で、Process Check という機能を使うことで system.processes.open_file_descriptors メトリクスを取ることができます。https://docs.datadoghq.com/integrations/process/#metricsただし、説明文にも書いてある通り dd-agent ユーザーが実行したプロセスしかこのメトリクスを取得することが出来ません。そのため、例えば Rails アプリケーションを動かすために puma プロセスを dev ユーザーで動かしていた場合、以下のような設定を書いても system.processes.open_file_descriptors メトリクスを取得することが出来ません。init_config:instances: - name: puma_worker search_string: ["puma: cluster worker"] exact_match: Falseこれは何故かというと、プロセスがオープンしているファイルディスクリプタ数を取得するためには /proc/<PID>/fd 以下にアクセスする必要があるためです。/proc/<PID>/fd ディレクトリはそのプロセスを実行したユーザーにしか read 権限がありません。$ ls -al /proc/1/fdls: cannot open directory /proc/1/fd: Permission denied$ sudo ls -al /proc/1 | grep fddr-x------. 2 root root 0 Apr 18 06:58 fddr-x------. 2 root root 0 May 11 06:12 fdinfoそのため、dd-agent はそのメトリクスを取得できないというわけです。ただし、dd-agent に root 権限を与えることで、閲覧は可能になります。公式ドキュメントではそのやり方が提示されていますが、セキュリティ的にリスクがあるため、推奨はされていません。docs.datadoghq.comさて、この記事の内容は dd-agent に root 権限を与えずに system.processes.open_file_descriptors メトリクスを取得するということでしたが、どうやれば良いのでしょう？DogStatsD を使うDatadog には DogStatsD という仕組みがあります。DogStatsD は任意のカスタムメトリクスを Datadog に送る方法の一つです。docs.datadoghq.com通常は以下のような言語毎のライブラリを公式が提供してくれているため、こちらを使うことで任意のカスタムメトリクスを送ることができます。github.comDogStatsD を通してメトリクスを送る際は、その送り側のプロセスは任意のユーザーで実行できます。そのため、上記の例にあったように dev ユーザーが puma プロセスを実行している場合は dev ユーザーで DogStatsD にメトリクスを送るプロセスを実行すれば、同じ dev ユーザーのため /proc/<PID>/fd への read 権限があります。思いついてみれば簡単なことでしたね。でもプログラミング言語で実装するのは面倒じゃない？少し本題とは反れますが、もう少しお手軽に DogStatsD にカスタムメトリクスを送りたいな、とも思います。そこで、調べてみたところ「DogStatsD には単純に専用のフォーマットで UDP パケットを送るだけで良い」ということを知りました。On Linux:vagrant@vagrant-ubuntu-14-04:~$ echo -n "custom_metric:60|g|#shell" >/dev/udp/localhost/8125orvagrant@vagrant-ubuntu-14-04:~$ echo -n "custom_metric:60|g|#shell" | nc -4u -w0 127.0.0.1 8125https://docs.datadoghq.com/developers/dogstatsd/#sending-metrics上記のように、DogStatsD のエンドポイントである localhost:8125 に custom_metric:60|g|#shell のようなフォーマットで UDP パケットを送ってやれば良いです。そのため、プロセスがオープンしているファイルディスクリプタ数のカスタムメトリクスを送るには、以下のコマンドを実行すれば良いです。$ echo -n "open_file_descriptors.puma_worker:$(ls /proc/$(pgrep -f -u dev 'puma: cluster worker' | head -1)/fd/ | wc -l):g" | nc -u -4 localhost 8125上記のコマンドを crontab などで毎分実行してやれば open_file_descriptors.puma_worker メトリクスを送ることができます。ただし、実際に本番で利用しているコマンドはそこまで単純ではなく、以下のようなシェルスクリプトを書いて実行しています。#!/bin/shif [ $# -ne 2 ]; then echo "Require 2 arguments" 1>&2 exit 1fiPROCESS_NAME=$1USER=$2# pgrep でシェルスクリプト自身のプロセスがマッチしてしまうため `grep -v` で除外する# CentOS 6 では pgrep に -a オプションがないため注意## 複数のプロセスが見つかっても無視するPROCESS=$(pgrep -f -a -u "${USER}" "${PROCESS_NAME}" | grep -v "$0" | head -1 | cut -f 1 -d ' ')if [ -z "${PROCESS}" ]; then echo "${PROCESS_NAME} does not exists" 1>&2 exit 1fils /proc/"${PROCESS}"/fd/ | wc -l#!/bin/bashif [ $# -ne 3 ]; then echo "Require 3 arguments" 1>&2 exit 1fiMETRIC_NAME=$1VARUE=$2METRIC_TYPE=$3echo -n "${METRIC_NAME}:${VARUE}|${METRIC_TYPE}" | nc -u -4 localhost 8125$ crontab -l* * * * * /path/to/send-to-dogstatsd.sh open_file_descriptors.puma_cluster_worker $(/path/to/get-open-fd.sh "puma: cluster worker" dev) g > /dev/null

Datadog で dd-agent に root 権限を与えずにプロセスがオープンしているファイルディスクリプタ数のメトリクスを取得する

社内勉強会の準備などで忙しく、レポートを書くのが遅れてしまいましたが、先週の 03/10 (土) に <a href="https://jawsdays2018.jaws-ug.jp/">JAWS DAYS 2018</a> へ行ってきました。

<img src="https://gyazo.com/5dafdbb66c5c6fd5a78aafeb83bd49c8.png" alt="image" />

今回が初参加でしたが、AWS ユーザーグループのお祭りという感じですごく盛り上がっていて楽しいイベントでした。

会社の同僚も 4 人ぐらい参加してました。

自分が参加したセッションと聞いた感想やメモをつらつら書いていきます。

(ただし Keynote は省きます)

社内勉強会の準備などで忙しく、レポートを書くのが遅れてしまいましたが、先週の 03/10 (土) に JAWS DAYS 2018 へ行ってきました。今回が初参加でしたが、AWS ユーザーグループのお祭りという感じですごく盛り上がっていて楽しいイベントでした。会社の同僚も 4 人ぐらい参加してました。自分が参加したセッションと聞いた感想やメモをつらつら書いていきます。(ただし Keynote は省きます)

JAWS DAYS 2018 に行ってきた

こんにちは、エンジニアの id:tsub511 です。最近頭痛がするのでヨガを始めましたが、効果が出ているのかよく分かりません。今回は m3.medium のインスタンスの CPU 負荷が高かったため t2.medium へ移行したら解決した話をします。m3.medium のインスタンスの CPU 負荷が高かった年始あたりから、週に数回ほど決まった時間に Mackerel でアラートが出ていました。CPU の Steal 値が異常に高く、全体としての使用率が 90 % を超えていました。ずっと原因が分からず、最初は Meltdown と Spectre のパッチを適用した関係で性能が低下したんじゃないか、などを疑っていました。しかし、ある時全く別の作業をしていたときに別のロールのインスタンスで同様に CPU 負荷が上がり、どちらも m3.medium というインスタンスタイプが共通していたことからなんとなくググってみたところ、以下の記事に辿り着きました。toritori0318.hatenadiary.jpどうやら、m3.medium というインスタンスタイプのみ CPU の Steal が発生しやすいようです。他にも同様の報告をしている記事をいくつか見つけました。https://forums.aws.amazon.com/thread.jspa?threadID=146585High CPU steal on EC2 m3.medium – Bonobos Tech Blog情報が 2014 年と古いですが、現に同様の事象が発生しているため、当時と変わっていない可能性が高いです。そのため、インスタンスタイプを変更することを検討しました。他のインスタンスタイプを検討m3.medium から別のインスタンスタイプに変更するに辺り、どのインスタンスタイプを選択するか、まずはコスト面で比較しました。calculator.s3.amazonaws.com順当に行けば m4 ファミリーが妥当なところですが、m4 ファミリーは medium サイズは提供していないため、費用がそれなりに増えてしまいます。この中で、m3.medium よりも安い t2.medium に目を付けました。t2.medium は m3.medium に比べると、 vCPU が 1 コア増え、メモリも 0.25 GB 増える上に料金が安くなるというかなりお得なインスタンスタイプです。m3.mediumインスタンスファミリー  インスタンスタイプ  プロセッサアーキテクチャ  vCPU  メモリ (GiB)  インスタンスストレージ（GB）  EBS 最適化利用  ネットワークパフォーマンス汎用  m3.medium  64 ビット  1  3.75  1 x 4  -  中https://aws.amazon.com/jp/ec2/previous-generation/t2.mediumモデル  vCPU  CPU クレジット/時  メモリ (GiB)  ストレージt2.medium  2  24  4  EBS のみhttps://aws.amazon.com/jp/ec2/instance-types/ただ、ここで安易に t2.medium を選択してはいけません。t2 ファミリーは「バースト可能パフォーマンスインスタンス」という特別な性質があります。T2 インスタンスについてT2 インスタンスについて、今までふわっとした理解しかなかったため、この機会に AWS のドキュメントをちゃんと読んでみました。docs.aws.amazon.com結論から言うと、弊社のサービスの性質上、決まった時間に Sidekiq のジョブがまとまって大量に実行されるため、普段は CPU 使用率は低く、ある時間だけ CPU 使用率が高くなるというまさに T2 インスタンスがピッタリなケースでした。CPU クレジットT2 インスタンスには CPU クレジットという概念があります。docs.aws.amazon.com1 CPU クレジットは 100 % の CPU 使用率を 1 分間稼働させることができます。t2.medium は CPU クレジットが 1 時間あたり 24 なので、100 % の CPU 使用率を 24 分間、あるいは 50 % の CPU 使用率を 48 分間、40 % の CPU 使用率なら 60 分間稼稼働させることができることになります。(ただし、t2.medium は vCPU が 2 コアなので、実際には 20 % の CPU 使用率で 60 分間の稼働)実際の CPU 使用率は平均で 20 % 以下に収まっていることが多い (たまにスパイクはする) ので、CPU クレジットが 24 ならまず問題ないです。この 40 % (20 %) という値をベースラインパフォーマンスと呼び、これを超えて CPU を使用することを「バースト」と呼びます。また、ベースラインパフォーマンスよりも CPU 使用率が下回っていた場合、クレジットバランスというものに余分な CPU クレジットが保存されます。クレジットバランスに保存された CPU クレジットは、CPU 負荷がベースラインパフォーマンスを上回った時に消費されます。つまり、余分な CPU クレジットは蓄積されて後で使うことができるということになります (ただし t2.medium の最大クレジットバランスは 576)。注意点としてはインスタンスを停止するとクレジットバランスに貯まった CPU クレジットは破棄されるというところでしょうか。T2 Unlimitedただ、T2 インスタンスを使う以上、気にしなければいけないのは CPU クレジットがなくなった場合は CPU のバーストができなくなるということです。CPU のバーストができないということはつまり、ベースラインパフォーマンス (t2.medium の場合は 20 %) 以上の CPU が使えなくなるということになります。ただし、去年の Re:Invent にて発表された T2 Unlimited という機能を有効にすることで CPU クレジットがなくなった場合でも自動的に CPU クレジットを追加され、CPU 使用に制限がかからなくなります。docs.aws.amazon.com具体的には、T2 Unlimited を有効にすると、CPU クレジット及びクレジットバランスがなくなった場合、余剰クレジットというものから消費されるようになります。最初の余剰クレジットは 24 時間で獲得できるクレジットの合計値となります。例えば t2.medium の場合、1 時間辺りの獲得クレジットは 24 なので 24 時間で 576 のクレジットが余剰クレジットになります。この 24 時間分の余剰クレジットは前借りのようなもので、消費した分だけ次のクレジット獲得時に余剰クレジットの支払いに使用されます。24 時間分の余剰クレジットまで全て使い切ってしまった場合でも、その後に消費した余剰クレジット分は追加で課金され、CPU のバーストは継続することが可能です。つまり、T2 Unlimited を有効にすれば T2 インスタンス特有の CPU クレジットの枯渇による CPU 使用制限の問題が解決されることになります。ただし、常にバーストし続けて追加でお金が発生し続けるような場合は、T2 インスタンスでなく普通にインスタンスタイプを利用したほうが懸命ですね。CPU クレジットの監視T2 Standard (非 T2 Unlimited) であっても、T2 Unlimited であっても、普段からどの程度 CPU がバーストしているかは監視しておいたほうが良いです。そのために、CloudWatch で CPUCreditUsage, CPUCreditBalance, CPUSurplusCreditBalance, CPUSurplusCreditsCharged という 4 つのメトリクスが提供されています。個人的には T2 Unlimited の場合、基本的には CPUSurplusCreditBalance と CPUSurplusCreditsCharged を監視しておけば良いと思います。CPUSurplusCreditBalance は消費された 24 時間分の余剰クレジット数CPUSurplusCreditsCharged は 24 時間分の余剰クレジットを使い切った後で更に消費される余剰クレジット数実際の監視には Datadog を利用しました (現在監視ツールを Datadog へ移行途中なため)。閾値はまだ感覚を掴めていないため、とりあえず厳しめにしてあります。m3.medium から t2.medium へインスタンスタイプを変更する弊社のサービスのインフラでは、Blue Green Deployment が可能な体制が整っているため、インスタンスタイプの変更は非常に簡単です。新しい環境のインスタンスは t2.medium で作成し、ELB からコネクションが流れるようになったら、古い環境のインスタンスを削除するだけです。ただ、EC2 の Launch Configuration + Auto Scaling Group を使っていたため、少し工夫が必要でした。T2 Unlimited の有効化は Launch Configuration ではサポートされていませんでした。Auto Scaling グループで T2 インスタンスを無制限に設定して起動するには起動テンプレートを使用する必要があります。起動設定では、T2 インスタンスを無制限として起動することがサポートされていません。https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/t2-unlimited.html#t2-auto-scaling-grpLaunch Template ならサポートされているものの、今から移行するのも大変ですし、何より Terraform がまだ Launch Template をサポートしていませんでした (2018/03/02 時点)。github.comどうしようと困っていたところ、以下の記事に助けられました。dev.classmethod.jpEC2 User Data を使って、インスタンス起動時に自身に対して T2 Unlimited を有効化する、という方法です。自分では全く思いつきませんでしたが、User Data も Terraform を使って管理できるのでかなりシンプルに実現できました。実際には以下の User Data を利用しました (CentOS を使っているため $ yum install aws-cli ができない)。#!/bin/bashset -x# Install aws-clicurl -L https://bootstrap.pypa.io/get-pip.py | pythonpip install awscli --upgrade# Enable T2 UnlimitedINSTANCE_ID=$(curl http://169.254.169.254/latest/meta-data/instance-id)REGION=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//')aws --region "${REGION}" ec2 describe-instance-credit-specifications --instance-id "${INSTANCE_ID}"aws --region "${REGION}" ec2 modify-instance-credit-specification --instance-credit-specification InstanceId="${INSTANCE_ID}",CpuCredits=unlimitedaws --region "${REGION}" ec2 describe-instance-credit-specifications --instance-id "${INSTANCE_ID}"これで、Auto Scaling Group によって起動したインスタンスに対して自動的に T2 Unlimited が有効になりました。インスタンスタイプを t2.medium に変更した結果実際に t2.medium のインスタンスを稼働させた結果、同程度の負荷がかかった際の CPU の Steal 値はほぼ 0 になりました。ちなみに t2.medium は vCPU が 2 つあるため、グラフの最大値は 200 % になっています。user 値が 90 % 程度なので、実質 CPU 使用率は 45 % 程度で、m3.medium の頃とほとんど性能は変わっていません。また、その他にも 5 分間のロードアベレージも全体的に下がっていました。まとめm3.medium のインスタンスを使っていて CPU 負荷に悩まされている場合はインスタンスタイプを変更すると解決するかもT2 インスタンスは適材適所で使えば費用を安く抑えられて非常に良いT2 Unlimited によって CPU クレジットがなくなる問題が解決されて安心して T2 インスタンスを使用できるようになったT2 Unlimited を Launch Configuration で有効化したい場合は User Data を使うと良いm3.medium が原因だったようで、解決して良かったです。日々のアラートに悩まされなくて良くなりました。

m3.medium のインスタンスの CPU 負荷が高かったため t2.medium へ移行した

先日 AWS Lambda の Golang サポートがリリースされました。

<a href="https://aws.amazon.com/jp/blogs/compute/announcing-go-support-for-aws-lambda/">Announcing Go Support for AWS Lambda | AWS Compute Blog</a>

今回は AWS Lambda を Golang で書きつつ、<a href="https://github.com/awslabs/serverless-application-model">SAM</a> へも入門したのでその辺りの知見とか作ったものについて紹介します。

先日 AWS Lambda の Golang サポートがリリースされました。Announcing Go Support for AWS Lambda | AWS Compute Blog今回は AWS Lambda を Golang で書きつつ、SAM へも入門したのでその辺りの知見とか作ったものについて紹介します。

AWS Lambda with Golang と SAM に入門した

この記事は <a href="https://adventar.org/calendars/2155">feedforce Advent Calendar 2017</a> の 9 日目の記事です。

昨日の記事は tmd45 さんの <a href="http://developer.feedforce.jp/entry/2017/12/08/090000">TypeScript 社内勉強会 完遂報告 - Feedforce Developer Blog</a> でした。 
TypeScript 社内勉強会には自分も参加していましたが、プロダクションのコードを書いているフロントエンドエンジニアの方から色々とアドバイスを頂いたり、他の言語の観点で議論が出来たりとても有意義な会でした！

さて、本題ですがワタクシ今年の 4 月に結婚をしました。

妻は Web コーダーで、割と Web サービスなどにも抵抗がなく普段から Slack や Kibela などを夫婦間で活用しています。

今回はその辺りで色々と工夫している部分を紹介できればと思います。

この記事は feedforce Advent Calendar 2017 の 9 日目の記事です。昨日の記事は tmd45 さんの TypeScript 社内勉強会 完遂報告 - Feedforce Developer Blog でした。さて、本題ですがワタクシ今年の 4 月に結婚をしました。妻は Web コーダーで、割と Web サービスなどにも抵抗がなく普段から Slack や Kibela などを夫婦間で活用しています。今回はその辺りで色々と工夫している部分を紹介できればと思います。

結婚して半年が経ったので工夫していることとか

こんにちは、バックエンドエンジニアの tsub (<a href="http://blog.hatena.ne.jp/tsub511/">id:tsub511</a>) です。

本日 AWS Re:Invent 2017 でコンテナ実行環境として新たに AWS Fargate と Amazon Elastic Container Service for Kubernetes (EKS) が発表されました。

昨日は発表が待ち遠しくて気が気じゃなかったですが、無事に予想通りマネージド Kubernetes サービスが発表されて大喜びです。

今回は AWS でコンテナを扱う上で、今までのサービスと合わせて選択肢がいくつかあって混乱すると思うので簡単にまとめました。

<h2>AWS でコンテナを動かすためのサービス</h2>

新しく 2 つのサービスが追加されたことで、これだけあります。
(見落としがなければ)

<ul>
<li>Amazon Elastic Beanstalk (EB)</li>
<li>Amazon Elastic Container Service (ECS)</li>
<li>AWS Batch</li>
<li><a href="https://aws.amazon.com/jp/eks/">Amazon Elastic Container Service for Kubernetes (EKS)</a> new!</li>
<li><a href="https://aws.amazon.com/jp/fargate/">AWS Fargate</a> new!</li>
</ul>


それぞれの特徴について説明していきます。

<h2>Amazon Elastic Beanstalk (EB)</h2>

※ EB については自分は全く触ったことがないので分からないままで書きます。

EB は Heroku のような PaaS です。
本来は Heroku と同じようにアプリケーションのコードをそのままデプロイして動かしますが、Docker もサポートしていて、コンテナとしてデプロイして動かすことができます。

小規模なサービス、チームなどでインフラの管理をしたくないというユースケースで使うことが多いと思います。

<h2>Amazon Elastic Container Service (ECS)</h2>

ECS は AWS が独自に開発しているマネージドなコンテナのオーケストレーションサービスです。
(コンテナのオーケストレーションについては <a href="#%E3%81%8A%E3%81%BE%E3%81%91:%20%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%82%AA%E3%83%BC%E3%82%B1%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">おまけ: コンテナのオーケストレーションについて</a> を参照)

EC2 の上で ecs-agent を動かすことで、ECS のクラスタとして認識させることができるため、非常にシンプルです。
ecs-agent が動いていれば、ECS を通して EC2 の上でコンテナを簡単に動かすことができます。

ECS 向けに awslogs という Docker 用の logging driver を提供していて、CloudWatch Logs との連携も簡単に行えます。

ECS 上でのコンテナは、ECS Task や ECS Service として動かします。
ECS Task には IAM Role を使った権限管理や VPC ネットワーク上で直接 Task を動かすことができ、セキュリティグループなどを利用することもできます。

ECS Service は ELB との連携があり、コンテナが起動したら自動的に ELB に紐付けたり、コンテナが終了したら ELB から外したり、といったことをやってくれます。

上記のように、他の AWS サービスとの連携がスムーズにできる点は非常に魅力的です。

<h2>AWS Batch</h2>

Batch はコンテナを使ったバッチコンピューティングに特化したサービスです。

バッチコンピューティングと言っても、決まった時間に決まった処理をするという cron のようなものではなく、
機械学習やスーパーコンピュータなどで利用するような大量の計算処理を必要とする場合に利用されるような基盤となります。

そういう背景もあり、主に CPU ベースでのコンテナの割り振り、ホストのオートスケーリングなどに強いです。

また、Batch はバックエンドで ECS を使っており、ジョブを動かすと実際に ECS Cluster が作られその上で Task が動いている様子を見ることもできます。
ECS を使っていることもあり、ログは自動的に awslogs logging driver によって CloudWatch Logs に送られたり、CloudWatch による ECS のメトリクスを見ることが可能です。

また、ECS と違って Job Queue も提供されていて、ジョブの状態管理なども可能となっています。
CloudWatch Events によりジョブの状態変化によるイベントドリブンな処理も可能です。

<h2><a href="https://aws.amazon.com/jp/eks/">Amazon Elastic Container Service for Kubernetes (EKS)</a> new!</h2>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Faws.amazon.com%2Fjp%2Feks%2F" title="Amazon EKS – マネージド型 Kubernetes サービス" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://aws.amazon.com/jp/eks/">aws.amazon.com</a></cite>

EKS はマネージドな Kubernetes を提供してくれるサービスです。
(現在はプレビュー版のみの提供)

ECS は AWS が独自に開発しているコンテナのオーケストレーションサービスでしたが、Kubernetes は Google が開発している OSS プロジェクトのコンテナのオーケストレーションツールです。
(コンテナのオーケストレーションについては <a href="#%E3%81%8A%E3%81%BE%E3%81%91:%20%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E3%81%AE%E3%82%AA%E3%83%BC%E3%82%B1%E3%82%B9%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6">おまけ: コンテナのオーケストレーションについて</a> を参照)

Kubernetes は OSS ということもあり、コミュニティが非常に活発で多くの開発者・企業が開発に協力しています。

Kubernetes を動かすための基盤はかなりたくさんの選択肢があり、あくまで EKS はそのうちの一つです。

特に、今まで AWS 上で Kubernetes 環境を構築するために様々なツールがありました (私が知っている範囲で)。

<ul>
<li><a href="https://github.com/kubernetes-incubator/kubespray">kubespray</a></li>
<li><a href="https://github.com/kubernetes-incubator/kube-aws">kube-aws</a></li>
<li><a href="https://github.com/kubernetes/kops">kops</a></li>
<li><a href="https://kubernetes.io/docs/reference/generated/kubeadm/">kubeadm</a></li>
<li><a href="https://coreos.com/tectonic/">Tectonic</a></li>
<li><a href="http://rancher.com/rancher-os/">Rancher</a></li>
</ul>


実際、今まで AWS 上で Kubernetes を利用していた人が多いようで、おそらくその方々は何らかのツールを用いて自前で構築していたと思います。

<a href="https://aws.amazon.com/jp/blogs/news/amazon-elastic-container-service-for-kubernetes/">https://aws.amazon.com/jp/blogs/news/amazon-elastic-container-service-for-kubernetes/</a>

<blockquote>AWS 上で Kubernetes を利用している多くのお客様がいます。実際、Cloud Native Computing Foundationによると、Kubernetes のワークロードの63％が AWS 上で動作しています。AWS は Kubernetes を実行するうえで人気の場所</blockquote>

これらのツールを使って、Kubernetes クラスタの構築・管理を簡単にすることができますが、やはりマスターノードを管理する必要はでてくると思います。

そこを AWS 側で管理・提供してくれるのが EKS となります。

EKS としては Kubernetes クラスタの管理だけでなく、ELB や IAM、VPC、Private Link、CloudTrail などとの連携も提供してくれているため、自前で Kubernetes クラスタを構築するよりも便利になっています。
後述の Fargate との連携も今後できるようになるとのことです。

また、既存の Kubernetes 用ツール群を使えるのも大きな強みです。

<h2><a href="https://aws.amazon.com/jp/fargate/">AWS Fargate</a> new!</h2>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Faws.amazon.com%2Fjp%2Ffargate%2F" title="AWS Fargate – サーバーやクラスターの管理が不要なコンテナの実行" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://aws.amazon.com/jp/fargate/">aws.amazon.com</a></cite>

Fargate は単体のサービスではなく ECS や EKS の上で使うことのできるサービスです。
(現在は北部バージニアリージョンのみの提供)

前述した ECS や EKS と違い、コンテナを動かすホストについて意識せず、コンテナそのものを動かすことだけに集中することができます。

どういうことかと言うと、Fargate では事前にホストを動かしておく必要はありません。

AWS VPC 環境と ECS のクラスター (名前空間的な意味で) を作っておけば、後はコンテナを起動するだけで自動的にホストを用意し、コンテナを実行してくれます。

また、ECS の上に乗っかっているので、使い方は簡単で ECS Task として起動する時に launch type として Fargate を指定するだけです。
その他、ECS Service でも使うことができます。
(EKS との連携についてはまだ情報が公開されていないため不明です)

ホストをこちら側で管理しないため、ホストの監視の方法などは気になるところですが、CloudWatch を通してホストのメトリクスは取れるようです。

<a href="https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overview">https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overview</a>

<blockquote>FargateではアプリケーションのログをCloudWatch Logsに送ることができます。サービスのメトリクス(CPUとメモリの利用率)もCloudWatchメトリクスとして利用可能です。可視化や監視、アプリケーションパフォーマンスの領域での我々のパートナーである、DataDog、Aquasec、Splunk、Twistlock、そしてNew RelicもFargateタスクをサポートしています。</blockquote>

また、Fargate に似たサービスとして <a href="https://azure.microsoft.com/ja-jp/services/container-instances/">Azure Container Instances (ACI)</a> や <a href="https://hyper.sh/">Hyper.sh</a> といったサービスも AWS 以外で提供されています。

<h2>おまけ: コンテナのオーケストレーションについて</h2>

コンテナを本番環境で動かそうとした時、コンテナをどのインスタンスで動かすか、どのインスタンスでコンテナが動いているのか、などコンテナの管理方法でいくつか問題が出てきます (あくまで一例です)。

そういった問題を解決するため、コンテナのスケジューリングやマネージングをするツールを用意する必要がありますが、それらを解決するためのツールが ECS や Kubernetes, Docker Swarm などと言ったオーケストレーションツールとなります。

ただし、どこにコンテナのスケジューリングやマネージングをする人が必要になってきます。
その人をマスターノードなどと呼び、次はこれを管理・冗長化などしなければいけないという問題がでてきます。

そのマスターノードの管理までマネージドで提供してくれているのが、ECS や EKS, <a href="https://cloud.google.com/kubernetes-engine/?hl=ja">GKE (Google Kubernetes Engine)</a>, <a href="https://azure.microsoft.com/ja-jp/services/container-service/">AKS (Azure Container Service)</a> などになります。

<h2>まとめ</h2>

<ul>
<li>EB

<ul>
<li>小規模なサービス・チームで使うと良さそう</li>
</ul>
</li>
<li>ECS

<ul>
<li>AWS 独自のコンテナのオーケストレーションサービス</li>
</ul>
</li>
<li>Batch

<ul>
<li>バッチコンピューティング基盤として使う</li>
</ul>
</li>
<li>EKS

<ul>
<li>Kubernetes を使ったコンテナのオーケストレーションサービス</li>
</ul>
</li>
<li>Fargate

<ul>
<li>検証環境・本番環境・ちょっとした処理など幅広く使える</li>
</ul>
</li>
</ul>


機能的に ECS と EKS の使い分けは難しいですが、学習コスト・導入コストの面で ECS に軍配は上がると思います。
ただ、コンテナを使う以上コミュニティが巨大な Kubernetes を使うことも大きなメリットです。

個人的には EKS を推していきたいです。

こんにちは、バックエンドエンジニアの tsub (id:tsub511) です。本日 AWS Re:Invent 2017 でコンテナ実行環境として新たに AWS Fargate と Amazon Elastic Container Service for Kubernetes (EKS) が発表されました。昨日は発表が待ち遠しくて気が気じゃなかったですが、無事に予想通りマネージド Kubernetes サービスが発表されて大喜びです。今回は AWS でコンテナを扱う上で、今までのサービスと合わせて選択肢がいくつかあって混乱すると思うので簡単にまとめました。AWS でコンテナを動かすためのサービス新しく 2 つのサービスが追加されたことで、これだけあります。(見落としがなければ)Amazon Elastic Beanstalk (EB)Amazon Elastic Container Service (ECS)AWS BatchAmazon Elastic Container Service for Kubernetes (EKS) new!AWS Fargate new!それぞれの特徴について説明していきます。Amazon Elastic Beanstalk (EB)※ EB については自分は全く触ったことがないので分からないままで書きます。EB は Heroku のような PaaS です。本来は Heroku と同じようにアプリケーションのコードをそのままデプロイして動かしますが、Docker もサポートしていて、コンテナとしてデプロイして動かすことができます。小規模なサービス、チームなどでインフラの管理をしたくないというユースケースで使うことが多いと思います。Amazon Elastic Container Service (ECS)ECS は AWS が独自に開発しているマネージドなコンテナのオーケストレーションサービスです。(コンテナのオーケストレーションについては おまけ: コンテナのオーケストレーションについて を参照)EC2 の上で ecs-agent を動かすことで、ECS のクラスタとして認識させることができるため、非常にシンプルです。ecs-agent が動いていれば、ECS を通して EC2 の上でコンテナを簡単に動かすことができます。ECS 向けに awslogs という Docker 用の logging driver を提供していて、CloudWatch Logs との連携も簡単に行えます。ECS 上でのコンテナは、ECS Task や ECS Service として動かします。ECS Task には IAM Role を使った権限管理や VPC ネットワーク上で直接 Task を動かすことができ、セキュリティグループなどを利用することもできます。ECS Service は ELB との連携があり、コンテナが起動したら自動的に ELB に紐付けたり、コンテナが終了したら ELB から外したり、といったことをやってくれます。上記のように、他の AWS サービスとの連携がスムーズにできる点は非常に魅力的です。AWS BatchBatch はコンテナを使ったバッチコンピューティングに特化したサービスです。バッチコンピューティングと言っても、決まった時間に決まった処理をするという cron のようなものではなく、機械学習やスーパーコンピュータなどで利用するような大量の計算処理を必要とする場合に利用されるような基盤となります。そういう背景もあり、主に CPU ベースでのコンテナの割り振り、ホストのオートスケーリングなどに強いです。また、Batch はバックエンドで ECS を使っており、ジョブを動かすと実際に ECS Cluster が作られその上で Task が動いている様子を見ることもできます。ECS を使っていることもあり、ログは自動的に awslogs logging driver によって CloudWatch Logs に送られたり、CloudWatch による ECS のメトリクスを見ることが可能です。また、ECS と違って Job Queue も提供されていて、ジョブの状態管理なども可能となっています。CloudWatch Events によりジョブの状態変化によるイベントドリブンな処理も可能です。Amazon Elastic Container Service for Kubernetes (EKS) new!aws.amazon.comEKS はマネージドな Kubernetes を提供してくれるサービスです。(現在はプレビュー版のみの提供)ECS は AWS が独自に開発しているコンテナのオーケストレーションサービスでしたが、Kubernetes は Google が開発している OSS プロジェクトのコンテナのオーケストレーションツールです。(コンテナのオーケストレーションについては おまけ: コンテナのオーケストレーションについて を参照)Kubernetes は OSS ということもあり、コミュニティが非常に活発で多くの開発者・企業が開発に協力しています。Kubernetes を動かすための基盤はかなりたくさんの選択肢があり、あくまで EKS はそのうちの一つです。特に、今まで AWS 上で Kubernetes 環境を構築するために様々なツールがありました (私が知っている範囲で)。kubespraykube-awskopskubeadmTectonicRancher実際、今まで AWS 上で Kubernetes を利用していた人が多いようで、おそらくその方々は何らかのツールを用いて自前で構築していたと思います。https://aws.amazon.com/jp/blogs/news/amazon-elastic-container-service-for-kubernetes/AWS 上で Kubernetes を利用している多くのお客様がいます。実際、Cloud Native Computing Foundationによると、Kubernetes のワークロードの63％が AWS 上で動作しています。AWS は Kubernetes を実行するうえで人気の場所これらのツールを使って、Kubernetes クラスタの構築・管理を簡単にすることができますが、やはりマスターノードを管理する必要はでてくると思います。そこを AWS 側で管理・提供してくれるのが EKS となります。EKS としては Kubernetes クラスタの管理だけでなく、ELB や IAM、VPC、Private Link、CloudTrail などとの連携も提供してくれているため、自前で Kubernetes クラスタを構築するよりも便利になっています。後述の Fargate との連携も今後できるようになるとのことです。また、既存の Kubernetes 用ツール群を使えるのも大きな強みです。AWS Fargate new!aws.amazon.comFargate は単体のサービスではなく ECS や EKS の上で使うことのできるサービスです。(現在は北部バージニアリージョンのみの提供)前述した ECS や EKS と違い、コンテナを動かすホストについて意識せず、コンテナそのものを動かすことだけに集中することができます。どういうことかと言うと、Fargate では事前にホストを動かしておく必要はありません。AWS VPC 環境と ECS のクラスター (名前空間的な意味で) を作っておけば、後はコンテナを起動するだけで自動的にホストを用意し、コンテナを実行してくれます。また、ECS の上に乗っかっているので、使い方は簡単で ECS Task として起動する時に launch type として Fargate を指定するだけです。その他、ECS Service でも使うことができます。(EKS との連携についてはまだ情報が公開されていないため不明です)ホストをこちら側で管理しないため、ホストの監視の方法などは気になるところですが、CloudWatch を通してホストのメトリクスは取れるようです。https://aws.amazon.com/jp/blogs/news/aws-fargate-a-product-overviewFargateではアプリケーションのログをCloudWatch Logsに送ることができます。サービスのメトリクス(CPUとメモリの利用率)もCloudWatchメトリクスとして利用可能です。可視化や監視、アプリケーションパフォーマンスの領域での我々のパートナーである、DataDog、Aquasec、Splunk、Twistlock、そしてNew RelicもFargateタスクをサポートしています。また、Fargate に似たサービスとして Azure Container Instances (ACI) や Hyper.sh といったサービスも AWS 以外で提供されています。おまけ: コンテナのオーケストレーションについてコンテナを本番環境で動かそうとした時、コンテナをどのインスタンスで動かすか、どのインスタンスでコンテナが動いているのか、などコンテナの管理方法でいくつか問題が出てきます (あくまで一例です)。そういった問題を解決するため、コンテナのスケジューリングやマネージングをするツールを用意する必要がありますが、それらを解決するためのツールが ECS や Kubernetes, Docker Swarm などと言ったオーケストレーションツールとなります。ただし、どこにコンテナのスケジューリングやマネージングをする人が必要になってきます。その人をマスターノードなどと呼び、次はこれを管理・冗長化などしなければいけないという問題がでてきます。そのマスターノードの管理までマネージドで提供してくれているのが、ECS や EKS, GKE (Google Kubernetes Engine), AKS (Azure Container Service) などになります。まとめEB小規模なサービス・チームで使うと良さそうECSAWS 独自のコンテナのオーケストレーションサービスBatchバッチコンピューティング基盤として使うEKSKubernetes を使ったコンテナのオーケストレーションサービスFargate検証環境・本番環境・ちょっとした処理など幅広く使える機能的に ECS と EKS の使い分けは難しいですが、学習コスト・導入コストの面で ECS に軍配は上がると思います。ただ、コンテナを使う以上コミュニティが巨大な Kubernetes を使うことも大きなメリットです。個人的には EKS を推していきたいです。

AWS でコンテナを動かすためのサービスまとめ

最近会社の同僚が <a href="http://developer.feedforce.jp/entry/2017/11/13/085404">Alfred Workflow を Go で書いたという LT を発表していて</a>面白そうだったので、自分も書いてみました。

以下のリポジトリで配布しています。

 <a href="https://github.com/tsub/alfred-datadog-workflow">tsub/alfred-datadog-workflow: A Alfred workflow to open Datadog pages</a>

Workflow のダウンロードリンクは<a href="https://github.com/tsub/alfred-datadog-workflow/releases">こちら</a>から最新バージョンのものをどうぞ。

<img src="https://gyazo.com/378dfd74e772c2d48776c5edd8ce6833.png" alt="image" />

最近会社の同僚が Alfred Workflow を Go で書いたという LT を発表していて面白そうだったので、自分も書いてみました。以下のリポジトリで配布しています。 tsub/alfred-datadog-workflow: A Alfred workflow to open Datadog pagesWorkflow のダウンロードリンクはこちらから最新バージョンのものをどうぞ。

Go で Datadog の Alfred Workflow を作った

<h2>[追記] この記事の内容について訂正</h2>

この記事内、及び Speaker Deck に投稿したスライドの中で誤っていた箇所があったため、訂正致します。

「ECS Optimized AMI では ecs-agent のバージョンが固定されない」という内容ですが、そういった問題はありませんでした。

AWS の方から直接アドバイスを頂いたところ、弊社が使用していた User Data のスクリプト内で <code>$ yum update</code> を実行していたことが原因となっていました。
<code>$ yum update</code> によりインスタンスを新規に立てた際に常に最新の ecs-agent や Docker がインストールされていました。

そのため、ECS Optimized AMI によってインストールされる ecs-agent と Docker のバージョンは以下のドキュメントで提示されているバージョンが常にインストールされることになります。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdocs.aws.amazon.com%2FAmazonECS%2Flatest%2Fdeveloperguide%2Fcontainer_agent_versions.html" title="Amazon ECS Container Agent Versions - Amazon EC2 Container Service" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/container_agent_versions.html">docs.aws.amazon.com</a></cite>

スライド中でも紹介しているように、一番困っていた問題が解消されたため AWS のサポートの方には非常に感謝をしております。

誤った情報を公開してしまい、申し訳ありませんでした。

<hr />

こんにちは、バックエンドエンジニアの tsub (<a href="http://blog.hatena.ne.jp/tsub511/" class="hatena-id-icon"><img src="https://cdn1.www.st-hatena.com/users/ts/tsub511/profile.gif" width="16" height="16" alt="" class="hatena-id-icon">id:tsub511</a>) です。

先日の社内 LT 大会にて、「ここがつらいよ ECS」というタイトルで発表してきました。

社内 LT 大会の記事についてはこちらをご覧ください。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdeveloper.feedforce.jp%2Fentry%2F2017%2F11%2F11%2F205600" title="FFLT開催しました！ - Feedforce Developer Blog" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://developer.feedforce.jp/entry/2017/11/11/205600">developer.feedforce.jp</a></cite>

私が発表したスライドはこちらです。

<script async class="speakerdeck-embed" data-id="4b214465b598443dbb55cfa35cd56aa3" data-ratio="1.33333333333333" src="//speakerdeck.com/assets/embed.js"></script>


せっかくですので、スライドにて紹介している「第一位 ecs-agent と Docker のバージョンが勝手に上がる」についてもう少し詳しく解説をしたいと思います。

<h2>ECS を用いたバッチシステムの運用について</h2>

弊社では Amazon ECS を用いたバッチシステムを運用しています。

Amazon ECS を用いたバッチシステムについての詳細は以前弊社の新卒エンジニアが書いてくれたので、こちらの記事をご覧ください。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.wantedly.com%2Fcompanies%2Ffeedforce%2Fpost_articles%2F59811" title="新卒１年目がバッチサーバーにECSを使ってDockerを導入した話 | feedforce Story" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://www.wantedly.com/companies/feedforce/post_articles/59811">www.wantedly.com</a></cite>

<h2>ecs-agent について</h2>

<a href="https://github.com/aws/amazon-ecs-agent">ecs-agent</a> とは、Amazon ECS にインスタンスを認識させるために動かす必要のあるエージェントです。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Faws%2Famazon-ecs-agent" title="aws/amazon-ecs-agent" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/aws/amazon-ecs-agent">github.com</a></cite>

<a href="https://hub.docker.com/r/amazon/amazon-ecs-agent/">Docker イメージが配布されていて</a>、通常はコンテナとして立ち上げます。

<a href="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html">ECS Optimized AMI</a> を利用していれば、インスタンスを起動したタイミングで勝手に立ち上げてくれるので、特に意識せずとも ECS を使えると思います。

<iframe src="https://hatenablog-parts.com/embed?url=http%3A%2F%2Fdocs.aws.amazon.com%2FAmazonECS%2Flatest%2Fdeveloperguide%2Fecs-optimized_AMI.html" title="Amazon ECS-Optimized AMI - Amazon EC2 Container Service" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html">docs.aws.amazon.com</a></cite>

ただし、ECS においてはこの ecs-agent がコンテナの配置、監視などを行っているため、かなり重要な役割となりますので、無視してはいけない存在です。

<h2>ecs-agent のバグによりいくつかのタスクが起動しなかった</h2>

以前、以下の Issue で取り上げられている ecs-agent v1.14.2 のバグにより ECS でいくつかのタスクが起動しなくなっていました。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Faws%2Famazon-ecs-agent%2Fissues%2F833" title="1.14.2 causing container instances to grind to a halt · Issue #833 · aws/amazon-ecs-agent" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/aws/amazon-ecs-agent/issues/833">github.com</a></cite>

2017/06/08 に ecs-agent を全コンテナインスタンスで v1.14.2 にアップデートしたことにより、06/08 から 06/13 にかけて 6 つのタスクが PENDING 状態のまま止まっていてインシデントが起きてしまいました。

この時は、上記 Issue でも書かれているように、一旦 <code>amazon/amazon-ecs-agent:latest</code> イメージにバグが発生する以前の v1.14.1 を Push し直してくれたことで、バージョンをロールバックすることはできました。

ただ、このような問題を再度起こさないためにも ecs-agent のバージョンは固定したいところですが、固定はできないという問題がここで発覚しました。

<h2>ECS Optimized AMI では ecs-agent のバージョンが固定されない</h2>

ECS Optimized AMI を使っていれば ecs-agent を自動的に立ち上げてくれますが、これが少々曲者です。

ECS Optimized AMI を使ってインスタンスを立ち上げた時、起動する ecs-agent のバージョンは常に最新のものが使われるのです。

しかも、AMI の中に ecs-agent がパッケージングされているかと思ったら、AMI をアップデートせずとも、インスタンスを新しく起動したら最新の ecs-agent が自動的に使用されます。

更に言うと、この ecs-agent のバージョンをユーザーが固定することはできず、最新バージョンしか選択肢がありません。

そのため、上述したようなバグが ecs-agent に含まれてしまった場合に回避不可能になります。

新たにインスタンスを立ち上げず、手動で ecs-agent をアップデートしなければ今動いてるもののバージョンが変わることはありませんが、オートスケーリングの設定をしていた場合、スケールアウトしたらそのインスタンスからは最新の ecs-agent が使われてしまう、という状況です。

この回避不可能な仕様に日々悩まされています。

ちなみに、Docker のバージョンも ecs-agent と同じようにバージョンが固定されていません。

<h2>どう運用しているか</h2>

では、弊社ではどう運用しているかというと、一部のコンテナインスタンスにカナリアリリース的にアップデートし、しばらく最新バージョンの ecs-agent をクラスタの中に紛れ込ませて稼働させておきます。

例えば 10 台のコンテナインスタンスを動かしていたとして、その内の 2, 3 台だけ ecs-agent をアップデートします。

アップデート自体は AWS コンソールから可能ですので簡単です。

数台だけアップデートした後 1, 2 週間ほど経ってから <a href="https://github.com/aws/amazon-ecs-agent/issues">ecs-agent の Issue</a> を確認して、特に大きな問題が起きてなさそうなら全台アップデートする、というような運用をしています。

これで今のところ ecs-agent のバグを踏む確率は多少減ったかな、という印象です。

<h2>まとめ</h2>

<ul>
<li>ecs-agent のアップデートによりバグが入り込む可能性がある</li>
<li>ECS Optimized AMI における ecs-agent と Docker のバージョン固定はできず、新しいインスタンスを起動すると最新が使われる</li>
<li>一部のコンテナインスタンスだけアップデートし、しばらく経って問題なければ全台アップデートする、という運用をしている</li>
</ul>


というわけで、今後も ECS による運用を続けていきますが、何か良いソリューションがあれば教えていただきたい次第です。

[追記] この記事の内容について訂正この記事内、及び Speaker Deck に投稿したスライドの中で誤っていた箇所があったため、訂正致します。「ECS Optimized AMI では ecs-agent のバージョンが固定されない」という内容ですが、そういった問題はありませんでした。AWS の方から直接アドバイスを頂いたところ、弊社が使用していた User Data のスクリプト内で $ yum update を実行していたことが原因となっていました。$ yum update によりインスタンスを新規に立てた際に常に最新の ecs-agent や Docker がインストールされていました。そのため、ECS Optimized AMI によってインストールされる ecs-agent と Docker のバージョンは以下のドキュメントで提示されているバージョンが常にインストールされることになります。docs.aws.amazon.comスライド中でも紹介しているように、一番困っていた問題が解消されたため AWS のサポートの方には非常に感謝をしております。誤った情報を公開してしまい、申し訳ありませんでした。こんにちは、バックエンドエンジニアの tsub (id:tsub511) です。先日の社内 LT 大会にて、「ここがつらいよ ECS」というタイトルで発表してきました。社内 LT 大会の記事についてはこちらをご覧ください。developer.feedforce.jp私が発表したスライドはこちらです。せっかくですので、スライドにて紹介している「第一位 ecs-agent と Docker のバージョンが勝手に上がる」についてもう少し詳しく解説をしたいと思います。ECS を用いたバッチシステムの運用について弊社では Amazon ECS を用いたバッチシステムを運用しています。Amazon ECS を用いたバッチシステムについての詳細は以前弊社の新卒エンジニアが書いてくれたので、こちらの記事をご覧ください。www.wantedly.comecs-agent についてecs-agent とは、Amazon ECS にインスタンスを認識させるために動かす必要のあるエージェントです。github.comDocker イメージが配布されていて、通常はコンテナとして立ち上げます。ECS Optimized AMI を利用していれば、インスタンスを起動したタイミングで勝手に立ち上げてくれるので、特に意識せずとも ECS を使えると思います。docs.aws.amazon.comただし、ECS においてはこの ecs-agent がコンテナの配置、監視などを行っているため、かなり重要な役割となりますので、無視してはいけない存在です。ecs-agent のバグによりいくつかのタスクが起動しなかった以前、以下の Issue で取り上げられている ecs-agent v1.14.2 のバグにより ECS でいくつかのタスクが起動しなくなっていました。github.com2017/06/08 に ecs-agent を全コンテナインスタンスで v1.14.2 にアップデートしたことにより、06/08 から 06/13 にかけて 6 つのタスクが PENDING 状態のまま止まっていてインシデントが起きてしまいました。この時は、上記 Issue でも書かれているように、一旦 amazon/amazon-ecs-agent:latest イメージにバグが発生する以前の v1.14.1 を Push し直してくれたことで、バージョンをロールバックすることはできました。ただ、このような問題を再度起こさないためにも ecs-agent のバージョンは固定したいところですが、固定はできないという問題がここで発覚しました。ECS Optimized AMI では ecs-agent のバージョンが固定されないECS Optimized AMI を使っていれば ecs-agent を自動的に立ち上げてくれますが、これが少々曲者です。ECS Optimized AMI を使ってインスタンスを立ち上げた時、起動する ecs-agent のバージョンは常に最新のものが使われるのです。しかも、AMI の中に ecs-agent がパッケージングされているかと思ったら、AMI をアップデートせずとも、インスタンスを新しく起動したら最新の ecs-agent が自動的に使用されます。更に言うと、この ecs-agent のバージョンをユーザーが固定することはできず、最新バージョンしか選択肢がありません。そのため、上述したようなバグが ecs-agent に含まれてしまった場合に回避不可能になります。新たにインスタンスを立ち上げず、手動で ecs-agent をアップデートしなければ今動いてるもののバージョンが変わることはありませんが、オートスケーリングの設定をしていた場合、スケールアウトしたらそのインスタンスからは最新の ecs-agent が使われてしまう、という状況です。この回避不可能な仕様に日々悩まされています。ちなみに、Docker のバージョンも ecs-agent と同じようにバージョンが固定されていません。どう運用しているかでは、弊社ではどう運用しているかというと、一部のコンテナインスタンスにカナリアリリース的にアップデートし、しばらく最新バージョンの ecs-agent をクラスタの中に紛れ込ませて稼働させておきます。例えば 10 台のコンテナインスタンスを動かしていたとして、その内の 2, 3 台だけ ecs-agent をアップデートします。アップデート自体は AWS コンソールから可能ですので簡単です。数台だけアップデートした後 1, 2 週間ほど経ってから ecs-agent の Issue を確認して、特に大きな問題が起きてなさそうなら全台アップデートする、というような運用をしています。これで今のところ ecs-agent のバグを踏む確率は多少減ったかな、という印象です。まとめecs-agent のアップデートによりバグが入り込む可能性があるECS Optimized AMI における ecs-agent と Docker のバージョン固定はできず、新しいインスタンスを起動すると最新が使われる一部のコンテナインスタンスだけアップデートし、しばらく経って問題なければ全台アップデートする、という運用をしているというわけで、今後も ECS による運用を続けていきますが、何か良いソリューションがあれば教えていただきたい次第です。

【2017/11/16 に訂正を追記しました】 社内 LT 大会で「ここがつらいよ ECS」というタイトルで発表しました

最近 Rust を少し学んでいたが、難しくて少し挫折しかけたのと、結局仕事への導入を考えるなら Go のほうが既に書ける人が何人かいる、というのもあり Go を書き始めた。

手初めてに欲しい CLI アプリケーションがあったのでそれをサクッと Go で書いてみた。

 <a href="https://github.com/tsub/s3-edit">tsub/s3-edit: Edit directly a file on Amazon S3</a>

最近 Rust を少し学んでいたが、難しくて少し挫折しかけたのと、結局仕事への導入を考えるなら Go のほうが既に書ける人が何人かいる、というのもあり Go を書き始めた。手初めてに欲しい CLI アプリケーションがあったのでそれをサクッと Go で書いてみた。 tsub/s3-edit: Edit directly a file on Amazon S3

Go で s3-edit という CLI アプリケーションを作った

今までずっと <a href="https://github.com/peco/peco">peco</a> を使ってきたが、そろそろ別のツールに変えてみるか&hellip;と思い立ったので <a href="https://github.com/junegunn/fzf">fzf</a> に移行した。

<a href="https://github.com/junegunn/fzf">junegunn/fzf: A command-line fuzzy finder written in Go</a>

自分は基本的に飽き性なので、定期的に環境を変えたくなる時期が来るのだが fzf が思ってたより良かったので紹介したい。

今までずっと peco を使ってきたが、そろそろ別のツールに変えてみるか…と思い立ったので fzf に移行した。junegunn/fzf: A command-line fuzzy finder written in Go自分は基本的に飽き性なので、定期的に環境を変えたくなる時期が来るのだが fzf が思ってたより良かったので紹介したい。

pecoからfzfに移行した

このブログはGitHub pagesを使って公開していたが、GKEに移行することにした。

<a href="https://blog.tsub.me/post/created-blog-by-hugo/">はてなブログからHugo on Github Pagesに移行しました</a>

これを聞いて、99%の人が、HugoでHTMLファイルを生成して公開しているならわざわざサーバーなんて必要ないんじゃないか？金の無駄じゃないか？と思うかもしれない。

自分もそう思う。

今回GKEを使ったのはGKEとk8sでのコンテナ運用を経験したかったことが非常に大きい。

会社ではECSを本番運用しているが、ECSに比べてk8sの方が良さそうな雰囲気しかないのでGKEの方も触っておこうかと思って移行した。

また、今のところブログ以外に個人で運用しているWebサービス等はないため、ブログがちょうどいい題材だった。

このブログはGitHub pagesを使って公開していたが、GKEに移行することにした。はてなブログからHugo on Github Pagesに移行しましたこれを聞いて、99%の人が、HugoでHTMLファイルを生成して公開しているならわざわざサーバーなんて必要ないんじゃないか？金の無駄じゃないか？と思うかもしれない。自分もそう思う。今回GKEを使ったのはGKEとk8sでのコンテナ運用を経験したかったことが非常に大きい。会社ではECSを本番運用しているが、ECSに比べてk8sの方が良さそうな雰囲気しかないのでGKEの方も触っておこうかと思って移行した。また、今のところブログ以外に個人で運用しているWebサービス等はないため、ブログがちょうどいい題材だった。

ブログをGKEでの運用に移行した

この記事は<a href="http://www.adventar.org/calendars/1427">feedforce Advent Calender 2016</a>の17日目の記事です。

前回の記事はpokotyamuによる<a href="http://pokotyamu.hatenablog.com/entry/2016/12/16/095524">HHKBを掃除した話</a>でした

無刻印のキーだからといってどのキーでも当てはまると思って適当にやるとものすごい罠に引っかかっちゃうんですね。

さて、今回は多くのエンジニアにとって重要なキーワードである情報収集についてです。

自分は多分社内ではわりと情報収集よくやってる方だと思っているのですが、自分が普段どんな方法で情報収集してるかを共有したかったので今回まとめてみました。

この記事はfeedforce Advent Calender 2016の17日目の記事です。前回の記事はpokotyamuによるHHKBを掃除した話でした無刻印のキーだからといってどのキーでも当てはまると思って適当にやるとものすごい罠に引っかかっちゃうんですね。さて、今回は多くのエンジニアにとって重要なキーワードである情報収集についてです。自分は多分社内ではわりと情報収集よくやってる方だと思っているのですが、自分が普段どんな方法で情報収集してるかを共有したかったので今回まとめてみました。

ぼくの情報収集方法

この記事は<a href="http://qiita.com/advent-calendar/2016/docker">Docker Advent Calendar 2016</a>の9日目の記事です。

先日AWSのre:Invent 2016で<a href="https://blox.github.io/">Blox</a>が発表されました。

BloxはEC2 Container Service(ECS)関連のオープンソースのツール群のことです。

そしてそのツールとは主にECSのカスタムスケジューラを指します

ECSはマネージドなスケジューラとマネージャを標準で備えていますが、Bloxはそれとは別に自分でホスティングする必要があります。

しかし、ECSに足りない機能を補ってくれるため導入するメリットは大きいでしょう。

<a href="https://aws.amazon.com/jp/blogs/news/monitor-cluster-state-with-amazon-ecs-event-stream/">先日リリースされた、CloudWatchEventsのECSイベントストリーム</a>を利用することで、よりスムーズにECSのクラスタの状態を監視してカスタムスケジューラを作ることができるようになりました。

Bloxはこれを使った一例と言えます

この記事ではBloxについて試してみて分かった内容や所感について書いていきます

<img src="https://i.gyazo.com/4c00e85fca7b228d7aa0d5f1e6dd1d27.png" alt="Blox thumbnail" />

この記事はDocker Advent Calendar 2016の9日目の記事です。先日AWSのre:Invent 2016でBloxが発表されました。BloxはEC2 Container Service(ECS)関連のオープンソースのツール群のことです。そしてそのツールとは主にECSのカスタムスケジューラを指しますECSはマネージドなスケジューラとマネージャを標準で備えていますが、Bloxはそれとは別に自分でホスティングする必要があります。しかし、ECSに足りない機能を補ってくれるため導入するメリットは大きいでしょう。先日リリースされた、CloudWatchEventsのECSイベントストリームを利用することで、よりスムーズにECSのクラスタの状態を監視してカスタムスケジューラを作ることができるようになりました。Bloxはこれを使った一例と言えますこの記事ではBloxについて試してみて分かった内容や所感について書いていきます

Blox Introduction

はてなブログをやめて、Hugo on Github Pagesに移行しました。

といっても、走りだしのブログであまり記事は多くないんですが..

移行した理由は、以前のブログを構築した際に、調子に乗ってはてなブログProに登録して独自ドメインを使っていたのですが、思ったよりも記事を書かずお金がちょっと勿体無いなーと思い始めてきたのでGithub Pagesに移行しました。

はてなブログをやめて、Hugo on Github Pagesに移行しました。といっても、走りだしのブログであまり記事は多くないんですが..移行した理由は、以前のブログを構築した際に、調子に乗ってはてなブログProに登録して独自ドメインを使っていたのですが、思ったよりも記事を書かずお金がちょっと勿体無いなーと思い始めてきたのでGithub Pagesに移行しました。

はてなブログからHugo on Github Pagesに移行しました

少し前にvimからneovimに移行したのですが、vimよりさくさくな気がする、程度でneovimの機能を特に活用していませんでした。

実はneovimにはterminal emulatorという機能があり、vimの中でshellを起動することができます。

例えばコードを書きつつ、rspecを実行したりpryやtigを使ったりなど、非常に便利です。

<a href="https://gyazo.com/ca4b9ef1599801f1948721befe274654.png"><img src="https://i.gyazo.com/ca4b9ef1599801f1948721befe274654.png" alt="" /></a>

少し前にvimからneovimに移行したのですが、vimよりさくさくな気がする、程度でneovimの機能を特に活用していませんでした。実はneovimにはterminal emulatorという機能があり、vimの中でshellを起動することができます。例えばコードを書きつつ、rspecを実行したりpryやtigを使ったりなど、非常に便利です。

neovimのterminal emulatorが便利すぎた

tokyo.ex #3 に参加してきました。

<a href="http://beam-lang.connpass.com/event/32704/">tokyo.ex #3</a>

前々からtokyo.ex #1, #2と気にはなっていたんですが、気づいた時には定員が埋まってまして今回やっと参加できました。

と思ってたらわりと席空いてたりキャンセル多かったり、定員超えてるからといって諦めなくても良かったみたいですね

参加してみての全体的な感想ですが、正直最近elixirを触ってなかったのでいい刺激になりました。

話の内容は非常にレベルが高く、大半は理解できませんでしたが、その分elixirの勢いとコミュニティの熱さは十分伝わってきました。

tokyo.ex #3 に参加してきました。tokyo.ex #3前々からtokyo.ex #1, #2と気にはなっていたんですが、気づいた時には定員が埋まってまして今回やっと参加できました。と思ってたらわりと席空いてたりキャンセル多かったり、定員超えてるからといって諦めなくても良かったみたいですね参加してみての全体的な感想ですが、正直最近elixirを触ってなかったのでいい刺激になりました。話の内容は非常にレベルが高く、大半は理解できませんでしたが、その分elixirの勢いとコミュニティの熱さは十分伝わってきました。

tokyo.ex #3 参加してきた

前回の記事でdocker containerに対してserverspecでテストができるようになりました。

<a href="https://blog.tsub.me/post/serverspec-for-docker/">serverspecでdocker containerに対してテストしたい</a>

dockerを扱う以上、containerは複数立てるのが普通です。

今回は複数のcontainerを立てた時にそれぞれのcontainerに対してテストする方法について書いていきます。

前回の記事でdocker containerに対してserverspecでテストができるようになりました。serverspecでdocker containerに対してテストしたいdockerを扱う以上、containerは複数立てるのが普通です。今回は複数のcontainerを立てた時にそれぞれのcontainerに対してテストする方法について書いていきます。

serverspecで複数のdocker containerに対してテストしたい

仕事でこれからdockerを使い始めるので、dockerを触りつつメモがてら記事に残していきます。