EKS5日目にして初めてセッションに参加しました。セッション参加して思ったこととしては、まず前を取ることが重要だなと感じました。英語読むスピードはどうしても日本語より遅くなってしまうので、追いきれないと思ったスライドは写真に収めてしまうのが吉ですね。動画見ていても思うことではあるのですが、画面読んでると話聞けなくなるし、聞いてると画面読めないという板挟みにあいます。すれば...?もちろん救いもあります。スライドと口頭の説明だけかと思いきや、デモとかもあって割と分かりやすいです。あと、事前知識がまったくない分野の話になると、英語がまったくわからなくなります。今回のケースだと、SELinuxが全然分かりませんでした。「SELInuxわかんないのかよ。インフラエンジニアの癖に。」という石を投げるのはやめてください。EKSのセキュリティについてのお話です。system層/AWS層というレイヤーで構築されていると思いますが、前者2つをセキュリティ性高くしていくにはどのようにすべきかという内容でした。セッションの内容(このパートは動画見た後に直すかもです)最初にセキュリティを考える上での基礎に触れていたように思います。modelについてです。EKSに対してどんな攻撃方法があるか?例えばL7での攻撃(XSS等)だとか、containerdやruncなどのオープンソースに潜んでいるバグを利用するもの、DDoS攻撃などが考えられます。一つ例を挙げてみます。とあるブログの記事で見つけたyamlを適用したら、マルウェアが含まれていたケース。これはごく稀にあるかもしれないと思ってしまいますよね。curlで落としてきたマニフェストを確認せずにapplyしてしまったりとか。マルウェアは自分たちのシステムにアクセスできてしまうし、関連しているAWSのマネージド・サービス、例えばRDSなんかもそうです。API層namespacesServiceAccountsこれはかなり効くと思っています。上であげた例のようなケースだと。serviceAccountNameをマニフェストに追記することになるので、権限をかなり意識するようになる。PoliciesPodSecurityPoliciesは下記のようなサンプルとともに深堀りされていました。確かにかなり効果的な制限が出来るようです。これはClusterリソースでPodが作成・更新されるときにシステムに受け入れられるように必要な条件を定義できるものだそうです。Contextでシステムコールを制限できる。単純にprivillagedを使うんでなくSecurityContext使って極力権限を絞っていくと良い。systemSELInux勉強不足であまり理解出来なかったので、勉強しつつ動画みれるようになったら補足して書きます。感想セッションもかなり学びがあると思いました。動画公開もあるので、なんとも言えないのですが...。Re:Inventは終わりでした!学習型カンファレンスと言われているように多くの学びがありました。反省点としては英語の能力が書けていたこと、同じ分野のワークショップを取り続けてしまったことでしょうか。アメリカ、(ほぼ)はじめての海外旅行なので、色々戸惑った点などあったのですが、それはまた別で記事にしようと思います。cost今まで受けてきたKubernetes系のWorkshopはカテゴリがContainerでしたが、今回はComputeです。最終日はセッション1つだけなので、Workshopとしては最後になります。EKSでも使用しているWorkshopをベースにして作成されたようです。運営は主にcomputeのスタッフさんが多かったですが、コンテナのエキスパートさんもいらっしゃって自分はその方に質問しました。資料はこちらec2spotworkshops.com午前にあったWorkshopとかぶる部分がちょいちょいあってその部分は割愛しています。午前のWorkshopはこちらの記事から。t.coWorkshopの流れ今までで一番親切なWorkshopの進行でした。後半になると内容の説明をしなくなってしまうスピーカーの方が多いのですが、このセッションはめっちゃ詳しく説明してくれて、例えばtaintsとtolerationとかも午前に比べて優しい説明(+優しい語彙)ですごくわかりやすかったです。最初にスピーカーの方が、本番でKubernetes使っている方をお聞きしていましたが、かなりの人数いらっしゃいました。Advancedのセッションだとやはり経験者が多いですね。スポットインスタンスを合わせて使っている人というものだと自分含めて数人くらいまで減ったので、スポットインスタンス使えているのは結構少ないのではとも感じました。導入EKS系のworkshopではお決まりのEKSクラスター構築から入りました。ちなみに作成するのは全てオンデマンドインスタンスです。クラスターが出来上がるまでの時間で、EKSのアーキテクチャについての説明が入りました。Planeの前段にはNLBがあるそうな。Planeからやっているんだ...どうやって実装しているのなど疑問におもいました。自分は存じ上げていなかったのですが、kube-ops-viewというKubernetesクラスターのnode/podを可視化するツールがあります。こちらはHelmを使って導入していきます。実際に入れてみると、エンドポイントが出来ます。エンドポイントにアクセスしてみると下記のように見えます。CPUとメモリも一緒に見れるのがいいですね。ドット絵っぽい感じもいいです。スポットインスタンスの導入スポットインスタンスの復習から入りました。なんとなく理解していたことではありますが、下記のページは知らなかったので驚きました。Terminationの頻度が出ているの便利ですね。aws.amazon.comeksctlを使ってスポットインスタンス(もしくはMixed-Instances)のNodeGroupを作成するには、eksctlのコマンドオプションだけでは難しいので、ClusterConfigを作成する必要がある。labelとtaintsを同時に作成しているけど、これは午前のWorkshopと同じなので言及は割愛。trueちなみにスポットとオンデマンドを混ぜるときには、結構工夫が必要。labelやtaintsをそれぞれで分けなくてはいけないから。スポットインスタンスかどうかを判断してあげて、Bootstrap.shにわたすコマンドオプションを分ける必要がある。fi午前にあったのと同じくスポットインスタンス削除のhandlerを入れるのですが、午前中に提示されたOSSと違ったので、少し戸惑いました。聞いてみたのですが、どうやら午前中に提示されたものを使用するべきみたいです。コードのベースは同じみたいなのですが...。ちなみに今回提示されたものは自分が現在使っているものでこちら(今後は保守されない...?)github.com今後はこっち使ったほうがいいよと言われたのがこちらt.coその後サンプルアプリケーションのデプロイとHPAとCAの導入を行いました。感想すごく丁寧なWorkshopでした。スタッフの方もかなり親切に声をかけてくれました。最後にスポットインスタンスのステッカーをいただけたのですが、非常に可愛いステッカーで気に入っています。VogelsのKeynoteを開始から1時間位みてきました。Firecrackerはcontainerdをベアメタルサーバごとに共通化させていて、それもオープンソースとして開発しているなど、非常に面白かったです。FargateとEC2の比較なんかも動画だとかなりわかりやすくてよかったです(本当に?とも思いましたが...)。Kubernetesをかぶる内容もありましたが、EKSでスポットインスタンスを使う方法やロギングでEFK構成を取る方法などをWorkshopで学んでいきました。実はCON203/CON205/CON206は続けて取ると丁度よくEKSのWorkshop全てを網羅出来るみたいです。ちなみにこのセッション、Walk-Upで行こうと思って並んで腰をおろしてPC開いたら予約できるようになっていました。予約して部屋戻って休憩できたので良かったです。他のWorkshopと同じようにチームハッシュの書かれたシールを貰って、https://dashboard.eventengine.run/にアクセスしてハッシュ打ち込むのかなと思っていたんですが、シールが用意されていませんでした。いったケースもあるんですね。チームハッシュの書かれた紙をスタッフの方が持っていて、その方が「これだよー」と提示して頂いて確認します。自分は写真を撮りました。Workshopの流れ他のKubernetesのセッションは3回目になるので、セットアップはかなりすんなり行きました。ここで結構詰まってしまう方が多いのと、eksctlでクラスターを作成するまでに時間がかかるので、CON203と同じく質問コーナーが設けられました。Fargate発表後というのもあり、そのへんの質問が多かったように感じます。EC2でのマニフェストをそのまま適用できるかというとそうでは無いようです。Checks正直に言いますとここはEKSの話というより、純粋なKubernetesでの話なのでMustではないのかなと感じました。内容としてもベーシックな内容でした。EKSEKSでSpotInstanceを上手く使う方法ですね。この辺を知りたくて来ました。このセッションでは、スポットインスタンスのNodeGroupを別で作成しています。true:PreferNoScheduleというtaintsをつけています。これを上手く利用します。taintsはtolerationsという概念とともにKubernetesで扱われる機能の一つです。Node側からSchedulingされるpodを制限できるのが強みです。pod側のnodeSelectorだと何も指定しなければ、どこのNodeでもスケジューリングされてしまいます。trueというtolerationsを持っていないものは、スポットインスタンスのnodeGroupには、スケジューリング出来ないことになります。taintsについているPreferNoScheduleはeffectと呼ばれるもので、Taintsを許容できないpodはSchedulingするのをなるべく避けるというものなっています。SpotInstanceはTerminateの2分前にEc2メタデータを通して通知を行います。それをキャッチしてハンドリングしないと、いきなりpodが死ぬことになります。そこで下記のものを使います。11月くらいからCommitが始まっているのでかなり最近のプロダクトになると思います。Terminateの通知を受けとったら、ノードにTaintをつけて他のpodがSchedulingされないようにします。Shutdownを促します。t.coこのDaemonSetはデフォルトで全てのNodeにSchedulingされますが、lifecycle=Ec2SpotというlabelのついたものだけにSchedulingされるように変更したほうがいい。サンプルアプリケーションfrontendのマニフェストで、Spotinstanceのtaintsを受容するようなtolerationsを設定し、nodeAffinityでlifecycle=Ec2Spotのラベルが付いたノードに優先的にスケジュールするように変更する。frontendのアプリケーションのみスポットインスタンスで運用されるようになった。Service(ESS)を構築します。自分は業務でESSに触ったことがなかったので新鮮でした。それとは並行して、fluentdのdaemonsetを作成していきます、一つ驚きだったのは、fluentdのdeploymentです。fluent/fluentd-kubernetes-daemonsetのimageかつ、fluentdの設定をConfigMapで持つ場合には、多少工夫をしなくてはいけないようです。initContainersでConfigMapをマウントして、/fluent/etc配下にコピーする必要性があるようです。(コンテナを扱うものとして恥ずかしくて仕方なかったものとしては/var/log/containers/*.logにコンテナのログが吐かれることを知らなかったことです)このDaemonSetが稼働するようになると、CloudWatchにデータが流れるようになります。Serviceを選択するとESSに流せるようになります。簡単!ただそのデータ投入はLambdaを使ってやるようで、Roleの準備とコストの考慮が必要になります。いざKibanaにログが入るとどうでしょう!?バージョン6.3のKibanaの画面きれい...!感想Workshopは質問出来てなんぼという感じがしました。強みはいろんなことを気軽に聞けるところ。自分の英語力がもっと高ければそういった機会を活かせたように感じました。FargateFargateの初心者向けセッションです。選ぶときに興味のあるトピックであれば、レベル関係なく受けようと思っていたのが良くなかったです。このセッションが4日間で受けたWorkshopのどれよりも簡単で少し物足りない感じがありました。それと疲れが非常に溜まっており体力的に限界だったのもあり、全て終わらせて途中で抜けてきました。導入ECS、特にFargateを使う上でどんな利点があるかを説明してくれました。EC2インスタンスを意識する必要が無いとかそんなような説明だったと思います。後は、AWSのプロダクトなので、完全に他のAWSサービスと統合されていてそれが強みとも言っていました。資料は下記リンクです。ecsworkshop.com業務で使っているのはawsコマンドですが、Workshopではecs-cliを利用しました。CLIのv2が出るってコンテナワークロードに出てきていたような...?CloudFormationでクラスターとALB(+TargetGroup)を作成するところからスタートです。完成したあとの構成は下記。Workshopの流れまずFrontendのRailsのアプリからデプロイしていきます。docker-composeの構文に少し似てますよね。envsubstってなんだろ?って思ったんですが、テンプレートエンジンみたいで、環境変数を埋め込んでくれるようです。普通に使っていきたい。通常CloudFormationで埋め込むパラメーター周りをecs-cli使うと、コマンド引数に持たせる感じになるようです。ファイルに持たせることも出来るんでしょうか?宣言的じゃないと使うのには躊躇があります。Fargateだと、aws-vpcモードがデフォルトだからか、vpcも指定が必要になってくるようです。自分が注目したのは、--private-dns-namespaceと--enable-service-discoveryです。$vpcServiceDiscoveryがEnableです。ECSはRoute53で実現されていたはずと思ってRoute53を見てみます。Zoneが作成されて、それが--private-dns-namespaceの引数に渡されているものと対応しています。それぞれのタスクがAレコードで入ってきていますね。DNSラウンドロビンで振り分けられる形になるわけです(おそらく...)。ヘルスチェックもRoute53から行われる形になりますね。恐ろしいことにあとこの作業をただただ2回繰り返します。最後にローカルでのテスト方法を行います。明快でタスク定義をdocker-compose.yamlにtranlateするコマンドがあるので、それを変換してdocker-composeを起動させるだけです。なんだか物足りない...。感想このWorkshopは出なくても良かったかも知れません。結局4日間でExpo行けていないので、もっと早めに切り上げてExpo行くなど柔軟に行動すべきでした。practicesお米食べたい気持ちが最高潮に達してしまった3日目2つ目のワークショップです。AWSのCodeシリーズを使ったWorkshopです。CodeBuild/CodeDeployは使ってみたほうがいいんだろうなとは昔から思っていたのですが、仕事に即活きるかとそうではないものだったため、ずっと手を出せずにいました。Workshopの流れ最初にDevOpsとは何かという説明から入りました。Responsbilityのお話とかですね。実践するとどんな利益があるのか?頻度の高いDeliveryやReliabilityの向上に約立つなど基本的な内容が多かったように感じます。そこからCodeシリーズを使ってCI/CDはどのように実現できるかというざっくりとしてお話がありました。どのプロダクトがどのフェーズの役割を担っているか説明が終わった後に実際にWorkshopに入りました。資料はGitHubにて既に公開されていました。github.com最終的には下記の図のようになります。最初に思わず「?」となってしまうことがありました。Prerequisitesとして、CodeCommitで構成するために必要な鍵を生成しろとあるんですが、Cloud9を使う場合には必要ありません。その直後からCloud9を使います!はて?なぜ必要だったのかいまだに謎です。起点はもちろんCodeCommitからになります。使えていませんが、正直、GitHubやBitbucketにくらべ、物足りない印象は拭えませんでした。サンプルコードはJavaのようです。CodeBuildCodeシリーズで使用するRoleとS3バケットをCloudFormationで作成し、いざCodeBuildの登場です。CodeBuildはProjectという単位でパイプライン群を分けていくようです。このプロジェクトでは、ソースとなるコードとアウトプットになるS3バケットが同じになるので、リポジトリと1対1で紐づくイメージを持っています。Jenkinsとかで言うところのパイプラインに相当すると認識です。実行する環境(Dockerイメージ)も共通となります。今回はJavaがインストールされたコンテナイメージを使用しています。いうファイルを作成し、その中にビルド工程を宣言していくようです。実はJenkins以外のCI/CDをあまり使ったことが無いのですが、yamlで書くのはすごく今どきって感じがしますよね。.artifact.filesで指定したものが最終的にzipに固めてS3にアップロードされます。devops-webapp-projectってな感じです。Eventをトリガーにすることも出来るようですね。マージとかを契機にするには、その辺を組み込まなきゃいけないのが若干手間に感じました。CodeDeployEC2インスタンスやVPCを作成するCloudFormationを展開させます。Agentがインストールされているそうです。deployment-groupというのを作っていきます。Applicationという括りの中にあって、どうやら本番・検証などのステージごとに作るみたいです。今回はEC2のタグでフィルターを掛けてKey=Name,Value=DevWebApp01を1つのグループとしています。appspec.ymlというファイルでこちらは定義していきます。scripts/basic_health_check.sh合わせてbuildspec.ymlを修正します。直でCodeDeployが指定できるのはいいですね。どっちもAWSがやっている強みが出てますね。CodePipelineはいやっとパイプラインで統合できます。これはGUIで作成していきます。これは本当に要求されるまま一つ一つ設定していくだけでした。Judgmentを組み込みました。感想CodeStarというのを使えばこれらが一発ででき出来上がるというので、そちらも試してみたくなりました。普通に使い勝手が良かったような印象はあります。EC2へのデプロイだったので、ECSやEKSで使いますか?と言われると首を捻ってしまうかもです。AI火曜のKeynoteの後に見たら偶然予約できました。新セッションが出てくるタイミングでUnreservedされた座席があったのだと思います。Walk-Upの列はとんでもないことになっていました。機械学習についての知識が全くない状態ではWorkshopの後半は、shift+Enterを繰り返すだけのただの人形と成り果ててしまいます。自分は人形と化しました。機械学習は3つに分類されるというお話から始まりました。自分が知っていたのはこのレベルまでです。learningに分類されるものだそうです。generatorとdiscriminatorという2つのネットワークを利用するそうな。generatorはその名のとおり、物を生み出す側で、DeepComposerでは音楽を生み出します。discriminatorはそれを評価してフィードバックすることで、よりクオリティを上げていくというものだそうです。説明の中では、オーケストラに例えていました。generatorは演奏者たち、そしてdiscriminatorは指揮者にあたるもののようです。素人でもどこか腑に落ちる(ような気持ちになる)説明でした。軽く説明を受けた後に簡単な小テストが行われました。上位に入るとスピーカーがもらえたようです。テスト自体は結構簡単だったのですが、なにより速さが足りない。スピーカーをもらうことが出来ませんでした。サンプルのモデルでGANsを体験してみるAWSコンソールからDeepComposerのページに飛んでみます。アカウントを頂いたのですが、どうやらre:Invent最終日の24時まで有効なようです。SageMaker使う部分に関してはお金かかると思いますし、結構複雑なアーキテクチャ組んでたので太っ腹ですね!DeepComposerをPCにつなげて、実際に弾き、それを録音することで音をインプットさせます。そのインプットした音を、モデルを用いてアレンジさせます。サンプルのモデルとして用意されていたのは、「Pop」「Rock」「Symphony」などの5種類です。みなさん思い思いにDeepComposerを奏でて、モデルによってアレンジさせていました。SageMakerを利用してモデルを作ってみる恥ずかしながら、まったく分かりませんでした!SageMakerからJupiterNotebookを起動させると、音楽生成GANsに関する基礎知識とそれに対応するPythonの構文がざーっと書かれていました。一応それぞれGoogle翻訳にかけて読みましたが、後半はわからない単語の応酬でなかなか厳しいものがありました。わかったのはモデルを生成する部分のAWSのアーキテクチャのみでした。DeepComposerは無事ゲットすることが出来ました!セッションを受けてると、SWAG行ったときに貰えるようです。(PM)2日目の午後からは、GameDayに参加してきました。JessyのKeynoteを見てきました。プレゼンの合間に生バンドの演奏が挟まり、それぞれのトピックのトレンドを象徴するかのような曲が流れました。Fargateでした。Graviton第2世代のM6gインスタンスにはとても期待を持っています。GameDayが始まる前にアメリカに渡ってきてからの2日間で自分が思ったより英語の聞き取りが出来ないこと、言葉も全然思ったように出てこないことを認識していました。そのため、チームを組んだときに言語の壁で足を引っ張ってしまうのでは無いかと心配でした。日本人4人で出れると有り難いなーなんて思っていたら、直前でなんとか組むことができました。自分はチームの他のメンバ全員と初対面でしたが、皆さん優しくて非常に助かりました。GameDayで大変だったこと内容とか書こうと思ったんですが、外部に垂れ流していいやつか分からなかったので、ぼやかします。システムの構成が中途半端になっているので、その部分の補完を行い、来る高トラフィックに備えるというのが趣旨でした。サービスの1つはEKS上で構築されていたので、自分がそこを担当することになりました。EKSやっているのが活きて本当に良かったです。単純にそれだけなら簡単なんですが、妨害が入ります。ネットワーク層での構成がゴリゴリ変えられて、普通にサービスダウンしました。いった妨害が入ることが頭に無かったので(説明をちゃんと聞いてなかった)、「ぼくなんかやってしまった?やってしまったの?」とパニクりました。踏み台にアクセスできなくなり、NewRelicにもデータ飛ばなくなったときはパニック最高潮でした。結果、指揮を取ってくれていた方が自分にヒントをくれたおかげで原因に気づくことができました。GameDayで得られたもの普段触らないサービスに触れたのは良かったと思います。良かった反面、やはり使い慣れていないサービスを使うのはかなり難しそうで、チームの方の中の一人はその部分に注力してくださっていたのですが、ハマりポイントもあったようで本当に大変そうでした。思い込みがいろんな問題の解決を遅くしてしまったように感じます。普段の障害調査もこういったふうに思い込みのせいで原因究明に行き詰まってしまっていたことがもしかしたらあったのかもと思いました。気づきを得られたのはとても良かったです。あとニット帽を得ました。結果80ぐらいいるチームの中で22位でした。一時は1位だったときもあったので悔しいですが、後半一度かなり落ちたので盛り返せたほうかなと思っています。Summitでやってほしいなと思う内容でした。Nightでそのままお話出来たのでとても嬉しかったです。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。