doridoridoriand’s diary

主に技術的なことを書いていく予定(たぶん)

Docker Buildxを利用してマルチアーキテクチャなdockerコンテナを作成する

classmethod 若槻さんの記事 Dockerのマルチアーキテクチャイメージについて調べてみた を読んでマルチアーキテクチャなdockerコンテナを作ってみたくなったので、忘備録として記事を書きます。

ビルドの方法が分からなかったので、dockerの公式サイトを覗くと記載がありました。 Leverage multi-CPU architecture support

Docker Official Imagesの githubリポジトリ を覗くと、対応しているアーキテクチャは2020年4月12日時点で

  • ARMv5 32bit (arm32v5) ※非公式
  • ARMv6 32bit (arm32v6)
  • ARMv7 32bit (arm32v7)
  • ARMv8 64bit (arm32v8)
  • Linux86-64 (amd64)
  • Windows x86-64 (windows-amd64)
  • IBM POWER8 (ppc64le) ※非公式
  • IBM z Systems (s390x) ※非公式
  • x86/i686 (i386) ※非公式

とのようです。(i386Linuxのみかな)

AWSが提供しているa1インスタンスのcpuinfoを見てみると

$ cat /proc/cpuinfo
processor   : 0
BogoMIPS    : 166.66
Features    : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part    : 0xd08
CPU revision    : 3

と表示されました。ARMのドキュメントを検索すると次のページがヒットしました
ARM Information Center

このページ書かれている内容から、

CPU implementer  : 0x41 => ARM Limited.
CPU part    : 0xd08 => Cortex-A72 processor.

ということが分かりました。Cortex-A72はARMv8アーキテクチャを採用しているCPUなので、問題なくマルチアーキテクチャビルドのコンテナが動くはずです。検証環境が整うことがわかったので今回は、

  1. マルチアーキテクチャのdockerコンテナをビルド
  2. docker hubにpush
  3. 手元のPCとARMインスタンスのEC2にpullしてきて動かす

を実施してみようと思います。

前準備

exprimental featureの有効化

マルチアーキテクチャのコンテナビルドのためには experimental feature(試験的な機能)を有効にする必要があります。Docker Desktopでは、

f:id:doridoridoriand:20200412203715p:plain
Docker Desktop

のように config.json を記載するエリアがあるので、 Use the Docker command line | Docker Documentation に記載されているJSONを入力します。

もしくは、ホームディレクトリ直下の .docker ディレクトリに config.json があるので、同様の内容を記載すればおkです(Linuxでも同じです)。

buildKitのインストール

今回使用する buildx というプラグインMoby BuildKit の拡張であるため、BuildKitのインストールが必要になります。 Macであれば

$ brew install buildkit

でもいいですし、公式に則った形でバイナリを /usr/local/bin 配下に設置してもいいでしょう。 buildctl コマンドが通ればインストール完了です。

$ buildctl
NAME:
   buildctl - build utility

USAGE:
   buildctl [global options] command [command options] [arguments...]

VERSION:
   v0.7.0

COMMANDS:
   du        disk usage
   prune     clean up build cache
   build, b  build
   debug     debug utilities
   help, h   Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --debug                enable debug output in logs
   --addr value           buildkitd address (default: "unix:///run/buildkit/buildkitd.sock")
   --tlsservername value  buildkitd server name for certificate validation
   --tlscacert value      CA certificate for validation
   --tlscert value        client certificate
   --tlskey value         client key
   --tlsdir value         directory containing CA certificate, client certificate, and client key
   --timeout value        timeout backend connection after value seconds (default: 5)
   --help, -h             show help
   --version, -v          print the version

buildxプラグインの追加

次に buildx というプラグインが必要になるので、 リポジトリ から最新のバイナリをダウンロードします。 ホームディレクトリにある .docker ディレクトリに cli-plugins というディレクトリを作成し、先程ダウンロードしたバイナリ docker-buildx という名前で保存します。

更に実行権限を付与します。

$ chmod a+x ~/.docker/cli-plugins/docker-buildx

以上が終わって、docker buildx コマンドが通れば利用可能です。

$ docker buildx

Usage:  docker buildx COMMAND

Build with BuildKit

Management Commands:
  imagetools  Commands to work on images in registry

Commands:
  bake        Build from a file
  build       Start a build
  create      Create a new builder instance
  inspect     Inspect current builder instance
  ls          List builder instances
  rm          Remove a builder instance
  stop        Stop builder instance
  use         Set the current builder instance
  version     Show buildx version information

Run 'docker buildx COMMAND --help' for more information on a command.

ビルド

今回は、rubyで実行したら実行マシンの現在時間を出力するコンテナを利用します。Dockerfileは以下の内容を利用します。

FROM ruby:2.6.3

CMD ruby -e "puts Time.now"

普通にビルド&実行をしてみると

$ docker build -t multi-arch-norm -f multi_arch_Dockerfile .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM ruby:2.6.3
 ---> d529acb9f124
Step 2/2 : CMD ruby -e "puts Time.now"
 ---> Running in f6ca4f8d0f5b
Removing intermediate container f6ca4f8d0f5b
 ---> 7a130a088630
Successfully built 7a130a088630
Successfully tagged multi-arch-norm:latest

$ docker run -it --rm multi-arch-norm
2020-04-12 12:15:34 +0000

と問題なく実行出来ること分かりました。

ではマルチアーキテクチャモードでビルドを実行してみます。

docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 -t doridoridoriand/multi-arch:latest . 
multiple platforms feature is currently not supported for docker driver. Please switch to a different driver (eg. "docker buildx create --use")

どうやら現在の docker driver ではマルチアーキテクチャのコンテナをビルドできないようです。指示に書いてあるとおり、 docker buildx create --use を実行します。

$ docker buildx create --use
$ ecstatic_roentgen

ランダムな名前でビルド用のコンテナが作成されました。

$ docker ps
CONTAINER ID        IMAGE                           COMMAND             CREATED             STATUS              PORTS               NAMES
8ce5fa2759e8        moby/buildkit:buildx-stable-1   "buildkitd"         6 minutes ago       Up 6 minutes                            buildx_buildkit_ecstatic_roentgen0

確かにbuildkitのコンテナが起動していることが分かります。

再度ビルドコマンドを実行します。

$ docker buildx build --platform linux/amd64,linux/arm64,linux/arm/v7 -t doridoridoriand/multi-arch:latest .
WARN[0000] No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load
[+] Building 133.1s (9/9) FINISHED
 => [internal] booting buildkit                                                                                                                                                                                                          7.3s
 => => pulling image moby/buildkit:buildx-stable-1                                                                                                                                                                                       6.5s
 => => creating container buildx_buildkit_ecstatic_roentgen0                                                                                                                                                                             0.7s
 => [internal] load .dockerignore                                                                                                                                                                                                        0.0s
 => => transferring context: 2B                                                                                                                                                                                                          0.0s
 => [internal] load build definition from Dockerfile

出力が長いので省略

無事ビルドができたようです。ただ、WARNには、

No output specified for docker-container driver. Build result will only remain in the build cache. To push result image into registry use --push or to load image into docker use --load

と書かれていることから、コンテナのビルド結果はキャッシュにしか残ってないようです。利用するには --push オプションでdocker hubにpushするか、--load オプションでローカルに持ってくるかが必要になるようです。今回は後で別マシンでpullしたいので、docker hubにpushすることにしました。

pushオプションを付けて再度実行したところ、無事にpushされ、単一のイメージタグで、複数のCPUアーキテクチャが利用出来るようになっています。

f:id:doridoridoriand:20200412223844p:plain
無事マルチアーキテクチャになっている

以下が実際にpushしたdocker imageになります。 multi-arch | Tags

pull&実行

実際に動くか試します。まずはx86-64(amd64)PCで実施します。cpuinfoは

processor       : 5
vendor_id       : GenuineIntel
cpu family      : 6
model           : 158
model name      : Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz

長いので省略

となっています。コンテナをpullして実行してみます。

$ docker pull doridoridoriand/multi-arch:latest
$ docker run -it --rm doridoridoriand/multi-arch:latest
2020-04-12 13:54:31 +0000

無事動きました。

次にARM(arm32v8)マシンで実施します。cpuinfoは

$ cat /proc/cpuinfo
processor       : 0
BogoMIPS        : 166.66
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

となっています。コンテナをpullして実行してみます。

$ sudo docker pull doridoridoriand/multi-arch:latest
$ sudo docker run -it --rm doridoridoriand/multi-arch:latest
2020-04-12 14:06:47 +0000

無事実行できました。

まとめ

Dockerがマルチアーキテクチャをサポートしたことで、IntelAMDのCPU以外でもDockerコンテナを動かす敷居が低くなりました。AWSで言えば、c系インスタンスとa系インスタンスのハイブリット構成でAPIサーバーを構築することも不可能ではなくなったので、実際に採用するかは別として、アーキテクティングの幅が広がったかと思います。

機会があれば、ミドルウェア等で試してみようと思います。

SREと私と時々障害

これは SRE Advent Calendar 2019 25日目の記事です。
世の中はクリスマスですね。特に意識していなくても浮足立ってしまうのは、まだ子供なせいなのでしょうか。
タイトルの付け方が何となく一昔前な気がするかもしれませんが、これしか思いつかなかったのと、結構気に入っているのでこのままでいきます。

注意: この記事はポエムが含まれております

現在とSREになるまでの変遷

現在私はとあるメディアサービスを提供している会社のSREチームでエンジニアとして働いています。所属しているチームは、

  • インフラエンジニア(私): 1人
  • バックエンドエンジニア: 3人

計4人で構成されています。

ここでSREチームに所属するまでの、私の変遷をご紹介したいと思います。

  • 2016年6月~12月 バックエンドエンジニアとして新卒で現在の部署に配属。とあるメッセンジャーアプリのAPIの開発 + Webフロントエンドの開発に従事。
  • 2017年3月より、インフラ局に所属。インフラエンジニアに転向し、先輩とともにインフラ業務に従事。12月に先輩が退職し、1人体制となる。
  • 2018年1月から、バックエンドエンジニアとしてインフラ業務に従事。
  • 2018年10月SREチーム発足。現在に至る。

元々バックエンドエンジニアでしたので、複数のLLを業務レベルで書くことは可能でした。私をインフラに誘ってくれた先輩は以下の理由によりインフラにも向いていそうだなと思ったようです。

  • 内定者時代からAWSの経験があった
  • サーバーのスペックに敏感だった
  • IDEVSCodeを使わず、ターミナルで開発していた(コンソールのVimで開発してました)

インフラも面白そうだなと思っていたので、そこまで迷うこともなく(コーディングから離れることに対する一抹の不安はありましたが)転向をお願いしました。 それから10ヶ月程度、現在の稼働サービスのインフラの状況から、運用に必要な実務レベルでのインフラ知識などを教えていただきました。

ここで転機となったのはその先輩の退職です。

  • サービス規模、ユーザー数拡大に負荷増大や、それに伴う既存の設計の問題の露呈
  • 老朽化に伴う移行作業
  • 最新技術等の導入
  • 障害対応業務

バックエンドエンジニアと協力して作業するのはもちろんですが、インフラ視点からのアドバイスをできるのが1人になってしまいました。
またインフラサイドにおける細かな運用業務も基本的には1人になりました。

今までのやり方をそのままやるのでは潰れてしまうので、私はできる限り自動化・容易化することに注力しました。ここでバックエンドエンジニアの力が活きてきました。
改善業務の一部として以下を行いました。

半年くらいをかけて、大小様々ですが100個程度のスクリプトを作成しました。このスクリプト達のおかげで、1人でもなんとかなるところまで持ってこられました。

SREの発足

次に転機となったのはSREチームの発足です。Googleが2017年の1月にSRE本のテキストを無料公開し、業界的にも徐々にSREに関して注目が高まっている頃でした。

2018年10月頃、開発責任者からSREチームの発足を告げられます。この時私はSREとしてうまく稼働できるかに関してはあまり自信がなく、現状のインフラ+αになる程度ではと思ってました。 これに関しては、SREと活動している現在も、私のミッションは主にインフラ+αなのですが、結果的に問題ないのではと思っています(※後述します)

バックエンドチームから切り離され、SREチームとなったメンバーは手探りで自分たちのミッションを決めていく必要がありました。そこでまずは本家に従おうということで、SRE本のチームでの輪読会を開きます。 ここから現在の開発組織における問題と対応策をみんなで話し合いました。

GoogleがO'Reillyから出版している「Site Reliability Engineering」は非常にボリュームがあり、また全部を輪読してもただの読書会になることが目に見えていたので、重要なところをかいつまみ、担当を割り振って実施しました。

一通りSREとしての先行事例を知ることができたので、次は自分たちの事業部に当てはめる作業になります。あくまでもGoogleの事例は、

「世界的に利用されているサービスを、複数の国と地域にまたがった開発組織を利用して、継続的かつ安定的なサービス運用する」

ために必要な仕組み等が多分に含まれています。

Googleのサービス群に比べれば小規模であり、ほとんどのサービス利用者が国内である、日本向けのサービスを展開している現在の事業部にそのまま当てはめるのは現実的ではありません。 また、SREチームは新規技術の開発というミッションも負っていたので、この時点で通常のSREチーム同様の働きはできなくなりました。

まずはじめにチームとして以下の内容に関して取り組むことになりました。

  • SLI/SLOを定義
  • 属人化している障害対応をもっと開発チーム全体で満遍なくできるようにする
  • 負荷試験の継続的な実施のための整備
  • ログ周りの整備可視化の充実化
  • トイルの継続的な改善・解消

SLI/SLOを定義に関しては私のミッションの1つだったので、実施背景を説明します。
この時すでにSREという単語が世間的にもある種のバズワードになっており、それに付随する単語も、聞いたことはあるが、具体的にどのようなもの分かっていないという状況だったと思われます。 そこでまずはSREとは何か、何のために存在するのか、目的は何なのかをはっきりさせるため、事業部のエンジニア全員が集まる開発定例にて勉強会を実施し、単語の定義及びミッションの共有の必要があると考え、実施しました。
なお、開発状況及び私自身のミッションの変更などにより、現在は別の担当者に引き継がれております。

状況の変化

現在の事業部の開発はビジネスに寄り添った開発スタイルを採っています。よって開発項目もビジネスの方向性の変更などにより俊敏に変更する必要があります。これ自体はとても素晴らしいことだと思っているので問題は無いのですが、SREチームのメンバーがSRE業務ではなく新規機能開発の方に比重を置かなくてはいけない時間が多くなりました。

またSREチームあるあるなのかもしれませんが、使用ミドルウェアのアップデートなど、定常的なインフラ業務が減っておらず、またインフラエンジニアが私だったこともあり、SREチームというよりは、バックエンドチームの新規機能開発チーム+インフラというような状況になっていました。

私自身も別のサービスのインフラを担当するなど、現在所属している事業部にとどまらず、現在出向している子会社のインフラを全般的に見るようになってきて、別チームと仕事をすることも増えてきました。

現在とこれから

現在はSREチームはKubernetesを利用したマイクロサービス基盤の開発・運用チームとなっております。現在EC2上で動いているアプリケーションも徐々にこのマイクロサービス基盤に移行されていく予定とのことです。
アプリケーションの移行に関しても、インフラエンジニアがメインで関わることなく、 バックエンドエンジニアが主体となって進められる状況を生み出せたことはとても良かったと考えております。

私は現在以下のミッションを実施しております

  • カオスエンジニアリングの導入・実施
  • 視聴品質の定常的な計測・可視化
  • 旧型インフラの改廃
  • 他サービスのインフラ・バックエンドエンジニア

インフラ半分SREのようなもの半分といったところでしょうか。
〇〇エンジニアといったロールが元々好きでは無いので(専門性は別にロールが無くても増やすことは出来ると考えているので)、個人的には望ましい状況になってきております。

SREというチームが必要なのではなく、SREの思想を少しでもバックエンドエンジニアが持っていることのほうがとても重要なので、以上のミッションを通して、バックエンドエンジニアにSREの思想及びその根底にあるインフラの知見を布教できればと考えております。


障害の話一度もしませんでしたね。。笑
正直なところ、ここには書けないので面識ある方はランチや飲みなどに誘ってください。話せる範囲で話します笑

AnsibleでKubernetes開発に必要なツールをインストールする

小ネタです。 Kubernetes開発用の作業用サーバーを構築する時に書いたので、何となく書いてみます。 EC2ならユーザーデータとかでやればええやんとかいう正論は受け付けません

一応理由を説明すると、

  • 起動時に毎回インストール作業が実行されるのがあまりよろしくない
  • インストールされているか否かをチェックするスクリプトを書き始めたら、そもそもユーザーデーターの責務では無い気がした(ユーザーデーターに記述されている内容は、起動時に毎回実行されるべきなはず)
  • 様々な資産があり、慣れているAnsibleで書いたほうが良いのでは?

という理由によるものです

インストール内容

作業サーバー(ツール群をインストールする対象のサーバー)のOSはAmazonLinux2を利用しています。今回は以下のツールをインストールしました

最近のツールはバイナリを放り込めば完成するパターンのものが多いので、インストールが楽になりました。 これらツールも例に漏れずバイナリ(もしくは単体のスクリプト)を放り込めばインストールが完了します

できたもの

早速結果を貼っちゃいます

kubectl

kubectx

kubens

eksctl

get_urlunarchive が素晴らしいので特筆すべきことは無いのですが、全てバージョン等を指定せず、Ansible実行時の最新を持ってくるように書いています。冪等性をあえて乱すような書き方をしていますが、Kubernetes界隈は開発が活発なので、常に新しいものを使うのが正義であると考え、この形にしています

Kubernetesの作業用サーバーを用意するといった考え方がもう古いような気もしますが、忘備録的にまとめてみました

クラウドベンダーのIPアドレス範囲の調べ方

小ネタです。クラウドベンダーがIPアドレスをどのくらい保有しているのか気になって調査したことがあったので、記事に起こしてみました。

今回調べたクラウドベンダー

今回はIPv4のみ調査しました。IPv6を含めると マンドクセ 膨大になりすぎて後述するスクリプトの計算が終わらないので。

AWS

AWSでは保有しているIPアドレスのCIDRブロックをAPIとして 公開 しています。 ページに記載されているCIDRブロックを計算すればIPアドレス保有数がわかります。 以下のようなコードを書いて個数を調べてみました

※計算時間短縮のため、並列演算をしています。実行するとCPUを使い切る挙動になるのでご注意ください。

試しに実行したところ、

$ ruby show_number_of_aws_ip_address.rb
I, [2019-09-28T20:25:00.222308 #61863]  INFO -- : Start to parse IP Address ranges of AWS.
I, [2019-09-28T20:25:00.786106 #61863]  INFO -- : Number of CIDR blocks: 1818
I, [2019-09-28T20:34:05.882460 #61863]  INFO -- : Completed to calculate number of IP addresses. Number of IP address of AWS: 93482928

9300万個所有しているようです。多いですね。

GCP

GCPではspfレコードに所有しているIPアドレス一覧を 記載 しています。 シェルで試しに引っ張ってきてみました。

$ netBlockAddr=(`dig -t txt _spf.google.com +short | tr ':' '\n' | grep net | tr ' ' '\n' | grep net`); for i in ${netBlockAddr[@]}; do dig -t txt $i +short; done | tr ' ' '\n' | grep ip4 | tr ':' '\n' | grep -v ip4;
35.190.247.0/24
64.233.160.0/19
66.102.0.0/20
66.249.80.0/20
72.14.192.0/18
74.125.0.0/16
108.177.8.0/21
173.194.0.0/16
209.85.128.0/17
216.58.192.0/19
216.239.32.0/19
172.217.0.0/19
172.217.32.0/20
172.217.128.0/19
172.217.160.0/20
172.217.192.0/19
108.177.96.0/19
35.191.0.0/16
130.211.0.0/22

※shell力がうんこなので、どなたかもっと良い書き方あったら教えて下さい(切実)

AWSの時と同様にスクリプトを書いてみました。

$ ruby show_number_of_gcp_ip_address.rb
I, [2019-09-28T21:15:23.028779 #91774]  INFO -- : Start to parse IP Address ranges of GCP.
I, [2019-09-28T21:15:23.678997 #91774]  INFO -- : Number of CIDR blocks: 19
I, [2019-09-28T21:15:25.140817 #91774]  INFO -- : Completed to calculate number of IP addresses. Number of IP address of GCP: 322816

めちゃくちゃ少ない。。!
本当に合っているのか不安になる少なさですね。GoogleAppEngineに関してはこのリストに入ってない可能性もあるので、もうちょっと調べてみます(多分)

Azure

Azureでは、以前はXMLによるファイル提供での公開だったのですが、その手法が 廃止予定 になり、その代わりとして Service Tag DiscoveryAPI がプレビュー公開されています。今回はService Tag DiscoveryAPIを利用した方法で計算してみます。

以下のスクリプトで調査可能です。

$ ruby show_number_of_azure_json_ip_address.rb
I, [2019-09-28T21:27:09.594383 #96119]  INFO -- : Start to parse IP Address ranges of Azure.
I, [2019-09-28T21:27:10.568397 #96119]  INFO -- : Number of CIDR blocks: 17009
I, [2019-09-28T21:29:32.258446 #96119]  INFO -- : Completed to calculate number of IP addresses. Number of IP address of Azure: 30981085

特筆すべきはCIDRブロックの多さですね。比較的細かいアドレスレンジを大量に集めているようです。


クラウドベンダーのアドレスをブロックしたいニッチな要求(このご時世実施したらメリットよりデメリットのほうが大きいと思いますが)の時などに参考になればと思います。
IBM CloudやOracle Cloud Platformも、時間を見つけて追加していこうと思います。

AWSにKubernetesクラスタを立てる with eksctl

仕事でKubernetesクラスタを触る機会があったので、家でも触ってみたいと思い、実施したことを忘備録的にまとめます。 AWSのページを確認すると

の2パターンが確認できます。 eksctl とはWeaveworksがメインで開発している、eksを簡単に構築・運用できるようにするためのコマンドラインツールになります。使用感としてはGCPgcloud コマンドに近いとのことです。 ( gcloud コマンド、ちゃんと使ったこと無いので伝聞なのが心苦しいですが。。)

コンソールから実施するタイプの方は、Kuberentes及びAWS CloudFormationなどにある程度慣れている方向けです(結構たいへんです)。
今回は構築・削除を簡単にしたいので、 eksctl を利用する方式を取ります。

※以下構築方法はあくまでプライベートでの検証用途です。会社の環境で同じ設定をすると、おそらく(というか確実に)インフラ or SRE エンジニアからぶっ飛ばされるので気をつけましょう。

やること

(全然セットアップしてない体で説明を開始します。してあるよって方はスキップでおk)

  1. IAMユーザーの作成&アクセスポリシーの追加
  2. AWS CLIのセットアップ
  3. eksctlのセットアップ
  4. 立てちゃう

とりあえずローカル以外でKubernetesを立てるというだけなら、eksctlコマンドを利用すれば驚くほど簡単になっています。

1. IAMユーザーの作成&アクセスポリシーの追加

1.

以下の用にIAMの画面からキーを発行します。 f:id:doridoridoriand:20190703185930p:plain ここでは ユーザー名: eks-power-access アクセスの種類: プラグラムによるアクセス

としました。

2.

次にポリシーをアタッチします。本当はダメな設定ですが、スポットの検証用ということでAdministrator権限をつけています。
(これが万一流出するとほぼ確実に不正利用されるので気をつけましょう) f:id:doridoridoriand:20190703190612p:plain

本来ならば、EKSの構築に必要な権限を調べて、それのみアタッチすべきですが、 ちょっと面倒くさかった 作業簡略化のためAdministratorをつけています

3.

最後入力内容を確認しましょう f:id:doridoridoriand:20190703191141p:plain

4.

キーが発行できたらCSVをダウンロードしておきましょう。画面からでも確認できますが、ダウンロードできるものはしておいたほうが何かと確実です。 f:id:doridoridoriand:20190703205514p:plain

2. AWS CLIのセットアップ

(正直ここまでセットアップ済みだよ!!って方がほとんどだと思いますが)
aws cliのインストールにはpythonが必要になります。お使いのPCがMacでしたらすでに導入されているので問題ないです。
python3系じゃないとだめだろ!!!馬鹿野郎!!!という方はググって頑張ってください。
pyenvもしくはvirtualenvを入れているという方はおそらく説明不要だと思うので、ここの文章はスキップで問題ないです。

他OSの方も、python導入(Windowsに関しては、スタンドアローンインストーラーがあるのでpythonを使わなくても使用可能です)に関してはググって頑張ってください。

以下コマンドで導入することができます

$ pip install awscli

Windowsスタンドアローンインストーラーの方はこちらを参照ください。

3. eksctlのセットアップ

こちらもすぐに終わります。

Linux

$ curl --silent --location "https://github.com/weaveworks/eksctl/releases/download/latest_release/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
$ sudo mv /tmp/eksctl /usr/local/bin

Mac

$ brew tap weaveworks/tap
$ brew install weaveworks/tap/eksctl

Windows

$ chocolatey install eksctl

ここに書きましたが、最新コマンドはこちらで確認をお願いします。
補完は好き好きで(あると便利です)

4. 立てちゃう

はい。立てちゃいます。

なんにも考えないで実行すると、以下コマンドになります

$ eksctl create cluster

ですが、このコマンドだと m5.large インスタンス2台を us-west-2 (オハイオ) リージョンにて、専用VPCを作成して構築することになります。あとクラスタ名がランダムで決まります。
検証用途にこのサイズのインスタンスは大きすぎるので、ある程度指定してあげましょう。

引数で指定してあげることもできますが、設定値はyamlで管理できるので、是非yamlにしましょう。

以下を指定しました。

以下のようなyamlになるかと思われます。

githubにもいくつかサンプルがあるので、是非参考にしてみてください。

作成するには、以下コマンドを実施します。

$ eksctl create cluster --config-file simple-kubernetes-with-eksctl.yml

10分程度で完成しました

$ eksctl create cluster --config-file simple-kubernetes-with-eksctl.yml
[ℹ]  using region ap-northeast-1
[ℹ]  setting availability zones to [ap-northeast-1d ap-northeast-1a ap-northeast-1c]
[ℹ]  subnets for ap-northeast-1d - public:192.168.0.0/19 private:192.168.96.0/19
[ℹ]  subnets for ap-northeast-1a - public:192.168.32.0/19 private:192.168.128.0/19
[ℹ]  subnets for ap-northeast-1c - public:192.168.64.0/19 private:192.168.160.0/19
[ℹ]  nodegroup "worker00" will use "ami-0dfbca8d183884f02" [AmazonLinux2/1.12]
[ℹ]  creating EKS cluster "kube00-tokyo" in "ap-northeast-1" region
[ℹ]  1 nodegroup (worker00) was included
[ℹ]  will create a CloudFormation stack for cluster itself and 1 nodegroup stack(s)
[ℹ]  if you encounter any issues, check CloudFormation console or try 'eksctl utils describe-stacks --region=ap-northeast-1 --name=kube00-tokyo'
[ℹ]  2 sequential tasks: { create cluster control plane "kube00-tokyo", create nodegroup "worker00" }
[ℹ]  building cluster stack "eksctl-kube00-tokyo-cluster"
[ℹ]  deploying stack "eksctl-kube00-tokyo-cluster"
[ℹ]  building nodegroup stack "eksctl-kube00-tokyo-nodegroup-worker00"
[ℹ]  --nodes-min=2 was set automatically for nodegroup worker00
[ℹ]  --nodes-max=2 was set automatically for nodegroup worker00
[ℹ]  deploying stack "eksctl-kube00-tokyo-nodegroup-worker00"
[✔]  all EKS cluster resource for "kube00-tokyo" had been created
[✔]  saved kubeconfig as "/Users/dorian/.kube/config"
[ℹ]  adding role "arn:aws:iam::xxxxxxxxxxxx:role/eksctl-kube00-tokyo-nodegroup-wor-NodeInstanceRole-13QV27O8G46HU" to auth ConfigMap
[ℹ]  nodegroup "worker00" has 0 node(s)
[ℹ]  waiting for at least 2 node(s) to become ready in "worker00"
[ℹ]  nodegroup "worker00" has 2 node(s)
[ℹ]  node "ip-192-168-19-13.ap-northeast-1.compute.internal" is ready
[ℹ]  node "ip-192-168-36-85.ap-northeast-1.compute.internal" is ready
[ℹ]  kubectl command should work with "/Users/dorian/.kube/config", try 'kubectl get nodes'
[✔]  EKS cluster "kube00-tokyo" in "ap-northeast-1" region is ready

では実際にkubectlコマンドが通るか試してみましょう。

$ kubectl get nodes
NAME                                               STATUS    ROLES     AGE       VERSION
ip-192-168-19-13.ap-northeast-1.compute.internal   Ready     <none>    8m        v1.12.7
ip-192-168-36-85.ap-northeast-1.compute.internal   Ready     <none>    8m        v1.12.7
$ kubectl describe nodes
Name:               ip-192-168-19-13.ap-northeast-1.compute.internal
Roles:              <none>
Labels:             alpha.eksctl.io/cluster-name=kube00-tokyo
                    alpha.eksctl.io/instance-id=i-0d24521d0fc8630ef
                    alpha.eksctl.io/nodegroup-name=worker00
                    beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/instance-type=t3.micro
                    beta.kubernetes.io/os=linux
                    failure-domain.beta.kubernetes.io/region=ap-northeast-1
                    failure-domain.beta.kubernetes.io/zone=ap-northeast-1d
                    kubernetes.io/hostname=ip-192-168-19-13.ap-northeast-1.compute.internal
Annotations:        node.alpha.kubernetes.io/ttl=0
                    volumes.kubernetes.io/controller-managed-attach-detach=true
CreationTimestamp:  Wed, 03 Jul 2019 20:20:37 +0900
Taints:             <none>
Unschedulable:      false
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  OutOfDisk        False   Wed, 03 Jul 2019 20:25:58 +0900   Wed, 03 Jul 2019 20:20:37 +0900   KubeletHasSufficientDisk     kubelet has sufficient disk space available
  MemoryPressure   False   Wed, 03 Jul 2019 20:25:58 +0900   Wed, 03 Jul 2019 20:20:37 +0900   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Wed, 03 Jul 2019 20:25:58 +0900   Wed, 03 Jul 2019 20:20:37 +0900   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Wed, 03 Jul 2019 20:25:58 +0900   Wed, 03 Jul 2019 20:20:37 +0900   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Wed, 03 Jul 2019 20:25:58 +0900   Wed, 03 Jul 2019 20:20:47 +0900   KubeletReady                 kubelet is posting ready status
Addresses:
  InternalIP:   192.168.19.13
  ExternalIP:   xxx.xxx.xxx.xxx
  InternalDNS:  ip-192-168-19-13.ap-northeast-1.compute.internal
  ExternalDNS:  ec2-xxx-xxx-xxx-xxx.ap-northeast-1.compute.amazonaws.com
  Hostname:     ip-192-168-19-13.ap-northeast-1.compute.internal
~~~~

問題なさそうですね。 では、一通り必要な検証が終わったとして、お金節約のため、クラスタを削除しましょう。以下コマンドで実施できます。

eksctl delete cluster --name kube00-tokyo
$ eksctl delete cluster --name kube00-tokyo
[ℹ]  using region ap-northeast-1
[ℹ]  deleting EKS cluster "kube00-tokyo"
[✔]  kubeconfig has been updated
[ℹ]  2 sequential tasks: { delete nodegroup "worker00", delete cluster control plane "kube00-tokyo" [async] }
[ℹ]  will delete stack "eksctl-kube00-tokyo-nodegroup-worker00"
[ℹ]  waiting for stack "eksctl-kube00-tokyo-nodegroup-worker00" to get deleted
[ℹ]  will delete stack "eksctl-kube00-tokyo-cluster"
[✔]  all cluster resources were deleted

削除されました。

Kubernetes自体はローカルでも検証することはできますが、クラウドベンダーの機能(AWSで言えばALBIngress, IAMとRBACの連携など)を試すときはサーバー上に構築する必要があります。
eksctlのおかげで、AWSでも簡単に構築できるようになったので、是非試してみてください。

バックエンドの種類を雑に把握する in AWS

ちょっと調査で使用したので、備忘録がてら記事に起こします。

静的サイトホスティングや、アセット系の保存場所S3を使うことはよくあることだと思います。 ですが、S3の静的サイトホスティングを有効にした状態で直接CNAMEやRoute53のエイリアスレコードを貼ってしまうとキャッシュされず、アクセスされるたびに毎回S3にGETが走ってしまうことになります。

個人のサイトなど低頻度アクセスなサイトであればそれほど問題にはなりませんが、商用サービスなどでは以下の問題が生じることがあります。

  • 転送容量によっては、CDNを経由しないと高額になる(とはいえ月間150TB以上転送したときに目の当たりにする問題だったりしますが)
  • GETリクエストに対する課金がCloudFront経由だった場合より高くなる
  • S3のAPIのRateLimitに引っかかる恐れがある(スパイクアクセスが発生したときに問題が表面化すると思われます)

またそもそも論としてS3は多機能ではありますが、メインの機能はストレージサービスですので、コンテンツ配信は別サービスに任せるのがアーキテクチャー的にも吉です。

ですが、以下理由により現在設定されているレコードのバックエンドが、S3直なのかCloudFront経由なのかを調べられない状況が存在します。

  • AWS CLIを現在叩けるPCではない
  • CLI or マネジメントコンソールに対するアクセス権限が無い

以上に対する対応方法として、簡易的にですが、以下の方法を使用することでバックエンドがS3直 or CloudFront経由かを判断できます。

  • curlでヘッダを見て判断する
  • digで返ってきたIPをnslookupする

curlでヘッダを見て判断する

CloudFront => S3となっているサイトに対してcurlを実行すると以下のような結果が返ってきます。

$ curl -I https://example.com/
HTTP/2 200
content-type: text/html
content-length: 1462
date: Sun, 09 Jun 2019 07:44:59 GMT
last-modified: Fri, 13 Oct 2017 03:20:02 GMT
etag: "ccde8929cea4684f8c27cac3f2060c5f"
accept-ranges: bytes
server: AmazonS3
x-cache: Hit from cloudfront
via: 1.1 d90dc9dxxxxxxxxxxxxxxxxxxxxxx.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT53
x-amz-cf-id: W0WBTwtWRofoio0ZqLSabHmPkbR3GtlPXXXXXXXXXXXXXXXXXX==

このときserverには AmazonS3 と入っており、一見バックエンドがS3直と勘違いしそうですが、

x-cache: Hit from cloudfront
x-amz-cf-pop: NRT53
x-amz-cf-id: W0WBTwtWRofoio0ZqLSabHmPkbR3GtlPlf_0UudiW7caw62BQ048WQ==

とあるように、CloudFront特有のヘッダがついていることがわかります。 それぞれ

  • x-cache: キャッシュのヒット可否及びTTL切れなどの情報
  • x-amz-cf-pop: どのPOPからレスポンスを受けているか
  • x-amz-cf-id: リクエストごとに付与されているユニークなID

となっています。 S3直のドメインにて同様にcurlを打つと、

curl -I https://example.com/
HTTP/1.1 200 OK
x-amz-id-2: INa97Ph1bsyjvUzPVj8jMxJPiON6ZIWnfXcUs30iyaSqJ46vs+xxxxxxxxxxxxxxxxJ+Evb4=
x-amz-request-id: E0000000000000F
Date: Sun, 09 Jun 2019 08:01:12 GMT
Last-Modified: Tue, 24 Jan 2017 11:03:17 GMT
ETag: "0553432f5fbc381066c8aee67a7afadb"
Accept-Ranges: bytes
Content-Type: text/html
Content-Length: 2728
Server: AmazonS3

というヘッダになっておりCloudFrontを挟んだときのような、キャッシュ情報などはありません。

digで返ってきたIPをnslookupする

IPアドレスにはられているDNSレコードを逆引きしてあげることにより、バックエンドがS3かCloudFrontかを知ることができます。

S3がバックエンドの場合、

$ dig example.com +short | xargs nslookup
Server:         127.0.1.1
Address:        127.0.1.1#53

Non-authoritative answer:
000.000.000.000.in-addr.arpa        name = s3-website-ap-northeast-1.amazonaws.com.

Authoritative answers can be found from:

とCNAMEに s3-website-ap-northeast-1.amazonaws.com. と入ってきます。

CloudFrontが間に挟んである場合、

$ dig exapmle.com +short | head -1 | xargs nslookup
Server:         127.0.1.1
Address:        127.0.1.1#53

Non-authoritative answer:
000.000.000.000.in-addr.arpa        name = server-000-000-000-000.nrt20.r.cloudfront.net.

Authoritative answers can be found from:

とCNAMEに server-000-000-000-000.nrt20.r.cloudfront.net. と入ってきます。

以上からバックエンドの種類を判断することが可能です。 実際の障害対応とかでは適切な権限を持ったエンジニアが対応するかと思われるので、上の手法を使うことは無いと思いますが、このような手法でもできないことは無いということをお伝えしたく記事にしました。

(ブログ書く頻度が低すぎて文体が毎回変わってますが、そのうち統一します。。)

Rubyのoptparseの挙動について

もう知ってる人にとっては、当たり前じゃん何言ってるのみたいな内容かもしれませんが、私は最近知ったので。。

Rubyには optparse というコマンドライン引数を読み取るライブラリが標準でついてくる。 これを使ってよくバッチ処理とかに使うスクリプトを書いてたりする。

この前書いたコードで以下のようなオプションを書いた。

OPTIONS = {}
OptionParser.new do |opt|
  opt.on('-n', '--no-daemon') {|v| OPTIONS[:no_daemon] = v}
  opt.parse!(ARGV)
end

デーモン状態で動くほうが通常モードだったアプリケーションなので、デーモン状態でない時を明示的にしたいときにと思い、 --no-daemon とした。 当初はこの引数を以下のように使用していた。

unless OPTIONS[:no_daemon]
  # :no_daemonがfalseだったときの処理(デーモン状態で動かしたいときの処理)
end

しかしどうも期待どおりの挙動を示してくれない(常にデーモン状態になる)のでドキュメントを見た。library optparse

--[no-]...などとすることで、否定型のオプションを指定することができます。

require 'optparse'
opt = OptionParser.new

opt.on('-a', '--foo') {|v| p v }
opt.on('--[no-]bar') {|v| p v }

opt.parse!(ARGV)
p ARGV

ruby sample.rb -a foo bar --bar baz --no-bar
# => true
     true
     **false**                              # <- --no-bar の指定による。
     ["foo", "bar", "baz"]

noってつけると否定形になって、falseが返ってくるのか

いつもTrueの感覚で書いていたので普通にミスった。

つわけで当初書いたここのコードブロックは

--no-daemonオプションあり => false
--no-daemonオプションなし => nil => false

となるので、常にデーモン状態となったわけだった。

最終的に以下のように修正した。

if OPTIONS[:no_daemon].nil?
  # :no_daemonがfalseだったときの処理(デーモン状態で動かしたいときの処理)
end

こっちのほうが素直な実装だとは思う。