Cloud Steps

1. はじめに EKS クラスターを作成したのはいいが、kubectl で Kubernetes API をコールした際、アクセス権限のエラーが出力されたということはありませんか。 よくある理由としては、デフォルト設定では、 Kubernetes API のコールは、クラスターを作成した IAM ユーザーや IAM ロールに限られます。 クラスターは、Terraform 等でクラスター作成され、Terraform 用 IAM ユーザーが利用されることが多いとおもいます。 そのため、自分自身のIAM ユーザーで Kubernetes API をコールしても、Kubernetes API にアクセスする権限が与えられていないため、Kubernetes API を呼び出すことができないのです。 こういった際にKubernetes API をコールする必要がある IAM ユーザーやロールにアクセス権限を与えるために利用されるのが、Access Entry です。 本記事では、Access Entry の説明や設定例について記述してゆきます。 2. Access Entry とは？ Access Entry とは、Kubernetes内部の設定ファイル（aws-auth ConfigMap）を触ることなく、AWS側（IAM）だけでEKSクラスターのアクセス権限を一元管理できる機能です。 2.1. クラスターの認証モード（Authentication Mode） Access Entry を利用するにあたり、EKSクラスターには「認証モード」という設定が用意されています。これにより、従来の権限管理から新しい Access Entry へどのように移行するかを制御できます。 認証モード 概要 補足・ユースケース CONFIG_MAP 従来の方式です。aws-auth ConfigMap のみを使用して権限を管理します。 互換性のために残されていますが、現在は非推奨です。 API_AND_CONFIG_MAP Access Entry（API）と aws-auth ConfigMap の両方を評価します。 既存のクラスターから新しい方式へ安全に移行したい場合に最適です。 API aws-auth ConfigMap を完全に無視し、Access Entry のみで権限を管理します。 新規クラスターにおけるベストプラクティスです。 2.2. Access Entryの必要性 Access Entry 以前は、aws-auth ConfigMap という機能で認証が利用されていましたが、現在は非推奨となっています。

はじめに Docker でコンテナの起動時に以下のようなエラーが生じました。 docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint conflict-test (c73c99ba5cbaeac0c0ce83e5cfeffc0354d68843ed320c4bfcea37ad05f26bd1): failed to bind host port for 0.0.0.0:8080:172.17.0.2:8080/tcp: address already in use エラーメッセージを確認すると、ホスト側の8080ポートがすでに別のプロセスによって使用されているため、コンテナのポート割り当てに失敗していることが分かります。 今回は、どのプロセスが対象のポートを使用しているのかを調査し、ポート競合の原因を特定する方法について紹介します。 ポートの競合が発生する理由 同じIPアドレス・ポート番号の組み合わせを複数のプロセスが同時に待ち受けることはできません。 例） アプリケーションA が ホスト側8080番ポート を使用していると、Dookcer コンテナに ホスト側8080番ポート を割り当てることができません。 競合したポートの調査 調査対象ポートを使用しているプロセスの特定 lsof -i :8080 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python3 2043035 john-doe 3u IPv4 10809101 0t0 TCP *:http-alt (LISTEN) プロセスID からプロセスの詳細を確認する ps -fp コマンドでプロセスの詳細を確認する。

1. はじめに Amazon CloudWatch Logs は、マネージドサービスでサーバーの構築やストレージの空き容量を気にせず運用することができる点で大きなメリットがあります。 ただ、便利な Amazon CloudWatch Logs ですが、ログデータが増えるにつれて、Amazon CloudWatch Logs へのログの取り込みやストレージ料金が高額になる恐れがあります。 一定期間経過したログは、Amazon CloudWatch Logs から削除し、別のコストパフォーマンスの良いストレージに移行することでログ保管にかかるコストを減らす方法についてまとめました。 2. 本記事の目的 Amazon CloudWatch Logs と Amazon S3 の料金特性を理解する。 安全かつ自動的にコストを抑えるための具体的な対策を知る。 3. Amazon CloudWatch Logs の料金は案外高い（課題） Amazon CloudWatch Logs は、ログの収集からリアルタイムの監視までをシームレスに行うことができる非常に便利な機能です。 しかしながら、前述したとおり、Amazon CloudWatch Logs にログを蓄え始めて、半年、一年と時間が経つうちに Amazon CloudWatch Logs の料金が高額になっていることがあります。 ここで Amazon CloudWatch Logs の料金体系を確認してみます。 ※　ここではログの取り込みとストア料金のみ 3.1. 無料利用枠 カテゴリ コスト データ取り込み 5GB/月 ストア 5GB/月 ※ 2026年5月23日現在 3.2. 有料利用枠 カテゴリ コスト データ取り込み 1GBあたり月額0.76米ドル ストア 圧縮時1GBあたり0.033米ドル ※ Amazon CloudWatch Logs では、データ取り込み時はログデータは圧縮されてませんが、保存される際にログデータを圧縮する。

はじめに 私はこれまで、AWS の構築では主に AWS CloudFormation を利用してきました。 今回、試しに Terraform を利用して構築を行ってみたところ、CloudFormation ではあまり意識することのなかった「state 管理」について考慮する必要があることを知りました。 CloudFormation 利用者の感覚では、「インフラの状態管理は AWS 側で行ってくれるもの」という認識が強かったため、Terraform で state を自分で管理する必要がある点には驚かされました。 CloudFormation では、スタックの状態管理は AWS 側の責務となっており、ユーザーが state の保存場所や排他制御を意識する場面はほとんどありません。 一方 Terraform では、state をどこに保存するか、チームでどのように共有するかまで考慮する必要があります。 本記事では、CloudFormation 経験者として Terraform の state 管理で戸惑った点をまとめます。 AWS CloudFormation では State を意識することが少なかった AWS CloudFormation の状態管理 Developers can deploy and update compute, database, and many other resources in a simple, declarative style that abstracts away the complexity of specific resource APIs. AWS CloudFormation is designed to allow resource lifecycles to be managed repeatably, predictable, and safely, while allowing for automatic rollbacks, automated state management, and management of resources across accounts and regions.

はじめに システム開発において、Docker を利用している方は多いのではないでしょうか。 Docker イメージは可搬性に優れており、検証環境でビルドしたイメージを本番環境に持ち込むことで、同一のアプリケーション実行環境を再現できます。 これにより、「環境差異による不具合」を減らせる点が、コンテナ技術の大きな強みです。 ただし、この可搬性は万能ではありません。 CPUアーキテクチャ（例：x86_64 と arm64）によっては、同一イメージでも動作しない場合があります。 そのため、「イメージさえあればどこでも同じように動く」という理解ではなく、実行環境との整合性を意識した運用が重要になります。 2. 本記事の結論 CPUアーキテクチャが一致しないとコンテナは起動できないです。 対策は、アーキテクチャを揃える or マルチアーキテクチャ対応が必要です。 3. 検証環境 3.1 ビルド環境 OS Amazon Linux 2 インスタンスタイプ t3.micro 3.2. コンテナ起動環境 OS Amazon Linux 2023 インスタンスタイプ t4g.micro 4. Dockerイメージのビルドとpush 4.1. CPU アーキテクチャの確認 sh-4.2$ uname -m x86_64 4.2. Docker から ECR にログインする sh-4.2$ aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin xxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com WARNING! Your password will be stored unencrypted in /home/ssm-user/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded 4.3. ビルド実施 sh-4.2$ sudo docker build -t cpu-arch-test . [+] Building 3.3s (5/5) FINISHED docker:default => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 125B 0.0s => [internal] load metadata for docker.io/library/ 〜以下、略〜 4.4. イメージにタグを付与する sh-4.2$ sudo docker tag cpu-arch-test:latest xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/cpu-arch-test:latest 4.5. ECR にイメージをプッシュする sh-4.2$ sudo docker push xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/cpu-arch-test:latest The push refers to repository [xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/cpu-arch-test] 3baf45fb4b5e: Pushed 538812a4b9bd: Pushed latest: digest: sha256:84d1632a2780f1e78d0857d90ce20707cda6b0b7d817ed52fb25c09e8dfd6057 size: 742 5. 別環境でpullして実行 5.1. CPU アーキテクチャを確認 sh-5.2$ uname -m aarch64 5.2. Docker から ECR にログインする sh-5.2$ aws ecr get-login-password --region us-west-2 | \ sudo docker login \ --username AWS \ --password-stdin xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com WARNING! Your password will be stored unencrypted in /root/.docker/config.json. Configure a credential helper to remove this warning. See https://docs.docker.com/engine/reference/commandline/login/#credentials-store Login Succeeded 5.3. ECR からイメージを Pull する sh-5.2$ sudo docker pull xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/cpu-arch-test:latest latest: Pulling from cpu-arch-test 2f7571f14c6f: Pull complete 04f0c7cfe47b: Pull complete Digest: sha256:84d1632a2780f1e78d0857d90ce20707cda6b0b7d817ed52fb25c09e8dfd6057 Status: Downloaded newer image for xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/cpu-arch-test:latest xxxxxxxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/cpu-arch-test:latest 5.4. コンテナを起動する exec /bin/bash: exec format error というエラーが出力され、コンテナの起動ができない。

1. はじめに システム開発をする中で、Docker でコンテナイメージのビルドされている方は多いのではないでしょうか。 コンテナイメージは、可搬性に優れており、どの環境（開発環境、検証環境、本番環境）でもアプリケーションを動作させることができるメリットがあり、開発者には大きな安心感を与えます。 しかしながら、イメージタグの理解が乏しいと、同じイメージを利用しているはずなのに、開発環境と本番環境で異なるイメージが利用されることがありえます。 この記事では、イメージタグの誤解から生じる問題と対策について記述します。 2. イメージタグに対する誤解 イメージタグは、ミュータブル（変更不可能）ではなく、ミュータブル（変更可能）です。 以下は検証結果です。 2.1. Dockerfile 作成 FROM alpine CMD ["echo", "This is Version 1.0 of the image!"] 2.2. ビルドする ~/Desktop/docker-test$ docker build -t test-image:1.0 . [+] Building 0.1s (5/5) FINISHED docker:default => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 98B 0.0s => [internal] load metadata for docker.io/library/alpine:latest 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [1/1] FROM docker.io/library/alpine:latest 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:d7cbeb7e099abb6ef223dbef9a5b39f11ba31c4ab8433 0.0s => => naming to docker.io/library/test-image:1.0 2.3. イメージを確認する タグとイメージID を確認する。

1. はじめに Kubernetes において、Pod のデプロイ戦略として、ローリングアップデート　が用意されています。 ローリングアップデートは、よく知られたデプロイ戦略です。 ただし、ローリングアップデートの実施前に確認しておかないと、想定していない障害や不具合が発生することがあります。 この記事では、ローリングアップデート実施前の確認事項をまとめています。 2. ローリングアップデートとは ローリングアップデートとは、システム全体停止を行わず、順次 Pod (コンテナ) を新しいバージョンの Pod へと段階的に入れ替えていくデプロイ手法です。 2.1. メリット ダウンタイムが生じない 常に一定数の Pod が存在しているため、サービス停止せず更新を行うことができます。 リスク分散 一度に全ての Pod を入れ替えないため、新しいバージョンに問題があった場合でも、影響範囲が少なくてすみます。 2.2. 注意点 ローリングアップデートの注意点として、古い Pod と 新しい Pod が一時的に存在する時間が生まれてしまうことです。 この時、ユーザーによって、アクセスする Pod が異なる場合があります。 こういった挙動で不具合が生じる可能性があるシステムで利用する場合は、注意が必要です。 3. 最初に確認したい全体観点 レプリカ数の確認 maxUnavailable / maxSurge Readiness / Liveness Probe 4. レプリカ数の確認 ローリングアップデートを行う事前確認として、レプリカの数を kubectl get deployment コマンド で確認を行うのが良いです。 レプリカ数が 1 の場合 maxUnavailable を 0 と設定したとしても Pod の切替時に処理落ちが発生する可能性があるため、レプリカ数 は、2 以上あることが望ましいで 5. maxUnavailable / maxSurge の設定 Kubernetes では、設定変更することで ローリングアップデート時の挙動を変更することが可能です。

1. はじめに Kubernetes の運用・保守していると Pod が正常に立ち上がらない問題に遭遇します。 立ち上がらない理由は、多くあると思いますが、初動確認手順は、おおよそ似通っているため、調査手順をまとめてみました。 不具合が起こった時、焦ってしまいますが、ある程度手順を決めておくと冷静に対処できると思います。 1.1. 検証環境について 本記事の動作確認には、ローカル環境で手軽に Kubernetes クラスターを構築できる kind (Kubernetes IN Docker) を使用しています。 2. 全体の調査フロー 異常な Pod を特定する kubectl get pod -A で稼働していない Pod の特定を行う。 Pending, CrashLoopBackOff, ImagePullBackOff など describe でイベントを確認する kubectl describe pod -n logsでコンテナの中を確認 kubectl logs -n 依存リソースも確認 3. 異常な Pod を特定する kubectl get pod -A で全名前空間の Pod を一覧する。 異常なステータスの Pod を特定する。ここでは、error-image-pod の ImagePullBackOff の状態であることがわかります。 kubectl get pod -A NAMESPACE NAME READY STATUS RESTARTS AGE default error-image-pod 0/1 ImagePullBackOff 0 20s kube-system coredns-7d764666f9-54bl2 1/1 Running 0 3m40s kube-system coredns-7d764666f9-kn66c 1/1 Running 0 3m40s kube-system etcd-kind-control-plane 1/1 Running 0 3m46s kube-system kindnet-q75q4 1/1 Running 0 3m40s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 3m46s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 3m45s kube-system kube-proxy-tw269 1/1 Running 0 3m40s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 3m46s 4. describe でイベントを確認する kubectl describe pod で pod のイベント詳細を確認する。

1. はじめに 本番環境のみのシステムで CLI (kubectl 等) のバージョンアップを行う必要がありました。 本番環境は、顧客が利用しているため、動作確認しない状態でバージョンアップすることはトラブルにつながると考えました。 そのため、EC2 から AMI を作成し、そこから検証用インスタンスを作成し、バージョンアップから動作確認ができるようにしました。 2. 想定している状況 サーバー（EC2）が本番環境のみでCLI等バージョンアップの検証を行いたい場合 ※ CLI のみなど軽微な検証を想定 3. 今回の作業の流れ 作業内容は以下の流れを想定しています。 EC2 から AMI の作成 ↓ AMI からEC2 インスタンス作成 ↓ バージョンアップの実施 ↓ 動作確認 ↓ 本番環境へ適用 4. EC2からAMIを作成 AWSマネジメントコンソール＞EC2＞対象のEC2を選択＞アクション＞イメージとテンプレート＞イメージを作成 を押下する。 任意のイメージ名を入力＞イメージを作成する。 5. AMIから検証EC2を作成 AWSマネジメントコンソール＞EC2＞AMI＞対象のAMIを選択＞AMIからインスタンスを起動を押下する。 AMI から作成するインスタンス名を入力する。 AMI から作成するインスタンスの配置するVPC やセキュリティグループ等を入力＞インスタンス起動を押下する。 6. バージョンアップの検証 新しく作成した EC2 インスタンス上でバージョンアップの検証を行う。 ※ ここは読者の皆様の環境に合わせて実施 8. 本番環境へ適用 6. バージョンアップの検証 で行った内容を本番環境で実施し、動作確認後問題なければ、作業完了です。 9. まとめ AMI を利用すると、EC2 の複製を簡単に作成することができるので、本番環境の EC2 から AMI を作成し、検証用インスタンスをらくらく作成可能です。 本番適用する前に検証を行いたいときはこの AMI を利用するとよいと検証作業がはかどります。

1. はじめに Linuxを学習する際、毎回EC2を手動で作成して環境を用意していました。 ただ、この作業は学習のたびに行う必要があり、少し手間だと感じていました。 そこで今回、AWS CDKを使ってLinux学習用のEC2環境をコードで構築できるようにしました。 これにより、 学習環境をすぐに作成できる 同じ環境を再現できる IaCの練習にもなる といったメリットを得ることができました。 この記事では、AWS CDKを使ってLinux学習環境を構築した方法を紹介します。 2. 背景 Linuxの学習では、実際にサーバーを触りながらコマンドを試すことが重要です。 しかし、学習用の環境を毎回手動で構築する場合、 EC2の作成 セキュリティグループの設定 VPC の作成 Session Manager の作成 などの作業が必要になります。 このような作業は毎回同じ手順であり、**自動化できる作業（Toil）**だと感じました。 そこで、AWS CDKを使って学習環境をIaC化することにしました。 3. 作ったもの Linux学習用のEC2環境を、AWS CDKで簡単に構築できるプロジェクトを作成しました。 GitHubはこちらです。 https://github.com/kohei-iwamoto-wa/linux_learning 主な特徴は以下です。 AWS CDKによるインフラ構築 Linux学習用EC2の自動作成 CDK destroyで環境削除可能 EventBridge Scheduler で CloudFormation スタックを定時で削除（リソース削除忘れ防止のため） 4. 構成 今回の構成はシンプルです。 AWS CDK VPC ↓ EC2 (Amazon Linux) ↓ Linux学習 CDKでEC2インスタンスを作成し、SSHで接続してLinuxコマンドの学習を行います。 5. CDKを使うメリット 今回CDKを使ったことで、次のメリットがありました。 5.1. 環境構築の自動化 手動でEC2を作成する必要がなくなり、 コマンド一つで学習環境を構築できるようになりました。 5.2. 再現性のある環境 IaCとして管理することで、 いつでも同じ構成の環境を再現できます。 5.3. IaCの練習になる CDKを使うことで、インフラをコードとして管理する 実践的な練習にもなりました。