@jedipunkz です。今まで自宅では PPPoE 接続をして Global IPv4 アドレスを取得して自宅にマイクラサーバーを外部公開しその接続を使って各端末でオンラインゲームやインターネットをしていました。ただ、IPoE 接続すると混雑時間を回避出来ると聞いていたので (これについては後術します)、普段のゲームや各端末のインターネット接続は IPoE 接続を利用しマイクラサーバーは PPPoE で公開、と出来ないかと考えました。IPoE は IPv4 over IPv6 のトンネリング接続するたため IPoE だけでは IPv4 Global IP アドレスによるサーバー公開は不可能だからです。 ここでは VyOS を使ってその両者を満たす接続の設定方法を記します。 要件 PPPoE して Global IPv4 を取得しサーバーを外部に提供 (その際に Dynamic DNS を利用 (自宅は Cloudflare)) サーバー以外の端末のトラヒックは IPoE 接続した経路に流す 回線はNTT フレッツ想定 (自分の場合は Asahi-net, IPv6 接続オプションあり, その他でも可) ISO イメージをビルド VyOS は Stable のバージョンは有償バージョンでないとダウンロード出来ませんがビルドすれば ISO イメージが作れます。その方法を記します。 2023/12 時点で最新の Stable バージョン 1.3.4 を指定 適当な Linux 端末でビルドしましたが Docker を利用できればどこでも良さそう git clone -b equuleus https://github.com/vyos/vyos-build cd vyos-build/ docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos vyos/vyos-build:equuleus bash ./configure --architecture amd64 --build-type release --version 1.3.4 sudo make iso ビルドが完了すると build/ ディレクトリ配下に iso イメージが出来上がっているはずです。 ...

こんにちは。jedipunkz です。 今回は、kubectl プラグインを開発したことがなかったので、Go の学習と合わせてためしに1つ作ってみたのでその内容を記したいと思います。 開発した kubectl plugin: kubectl-fuzzy-login 下記が今回開発した kubectl プラグインです。 https://github.com/jedipunkz/kubectl-fuzzy-login 何が出来るか 下記のキャプチャをご覧頂くと一目瞭然だと思います。 Kubernetes のポッドとコンテナをインクリメンタルサーチしつつ選択し、最終的にコンテナにログイン出来るプラグインになっています。コンテナがサイドカー構成になっていた場合は、そのうちのどのコンテナにログインするかもインクリメンタルサーチ出来ます。なお、このプラグインは Go で開発しました。 インストール方法 Krew を利用している場合は下記の操作でインストールできます。Krew が事前にインストールされている必要があります。 git clone https://github.com/jedipunkz/kubectl-fuzzy-login.git kubectl krew install --manifest=./kubectl-fuzzy-login/krew/fuzzy-login.yaml マニュアル操作でインストールする場合は下記です。 git clone https://github.com/jedipunkz/kubectl-fuzzy-login.git cd kubectl-fuzzy-login go build cp kubectl-fuzzy-login /your/bin/path 使用方法 オプション無しで、全 Namespaces を対象に検索・ログインする オプションを使用しない場合は下記のように実行します。 kubectl fuzzy login まず Pod を選択します。Pod 名の一部を入力することでインクリメンタル・ファジー検索出来ます。その Pod に複数のコンテナ (サイドカー) がある場合、更にコンテナをインクリメンタルサーチ出来ます。最終的にコンテナを選択し Enter ボタンを押すことでコンテナにログイン出来ます。ただしコンテナイメージにシェルが入っていない場合は入ることが出来ません。 シェル指定 また下記のように -s オプションでデフォルトのシェルを指定することもできます。 kubectl fuzzy login -s /bin/bash Namespace 指定 Namespace を -n オプションで指定することもできます。 ...

こんにちは。jedipunkz🚀 です。 以前こちらの PipeCD 検証の記事 で Progressive Deliver について調査したのですが、Kubernetes でこの Progressive Delivery を実現する方法を調べておきたいなと思って手元の Macbook 上で検証してみたのでその際の手順を記そうかと思います。 Progressive Delivery の概要 ここで概要だけ記しておきます。Canary リリースは新しいデプロイメントをある程度の割合だけリリースし、徐々にリリースを進行させるデプロイ方式ということはご存知だと思いますが、Progressive Delivery はその過程で 新しいデプロイメントの統計情報を得る 予め定義したデプロイ成功定義に対して条件満たしているかを過程毎にチェックする チェック OK であれば次の過程にデプロイを進める 予め定義した幾つかのデプロイ過程を全て終えるとデプロイ完了となる というステップを経ます。 用いるソフトウェア Kubernetes で Progressive Delivery を実現するには下記のソフトウェアを用いる事が可能です。 また今回の手順は MacOS を前提に記します。 Argo Rollouts Prometheus Istio Kubernetes (今回は Minikube を使いました) 事前の準備 Istio Istio をダウンロードします。 curl -L https://istio.io/downloadIstio | ISTIO_VERSION=17.2 sh - Istio を Minikube にデプロイします。 cd istio-17.2 istioctl install --set profile=demo -y Kubernetes Namespace default で起動した Pod が自動的に Envoy サイドカーを取得するように設定します。 ...

こんにちは @jedipunkz 🚀 です。 普段仕事で AWS ECS を使っていて Autoscallng Group によってアプリケーションを据えケールさせて運用していますが、運用している中でより高速にオートスケール出来ないものだろうか？と思うシチュエーションが何回か発生し、対応方法について模索していました。 実際に発生したシチュエーション 下記はコンテナ毎の CPU 使用率です。1分未満の間に急激にアクセスが増えコンテナの CPU 使用率が 100% に達し (実際には vCPU に基づいて 200% となっている)、ECS Service のヘルスチェックに Fail して、コンテナが落ち、新しいコンテナは起動するものの、アクセス不可に耐えられず、コンテナ停止と起動を繰り返すといった状況でした。 Autoscaling Policy, Cloudwatch Metrics Alarm の調整 まず最初に考えたのが下記の値の調整です。 aws_app_autoscaling_policy の cooldown 値 aws_cloudwatch_metric_alarm の period 値 具体的には 60sec となっていた値を 10sec などに変更しました。これによって 60sec のインターバルでしきい値計算してスケールさせていたところを 10sec にインターバルを縮めつつスケールさせる。つまりより迅速にスケールさせることで上記のシチュエーションに耐えられるのではと考えました。 ですが、結果は NG でした。 下記は Cloudwatch Metrics の様子です。データはプロットされているものの、データ不足 という状態に陥っている事がわかります。 実際に ECS はこの設定をした Metrics Alarm ではスケールしてくれませんでした。 高解像度メトリクスの利用について であれば高解像度メトリクス を利用すれば良いのではと考えました。 ...

こんにちは @jedipunkz 🚀 です。 ECS 構成をもう少しセキュアに保てる構成はないものだろうかと模索しているなかで Sysdig を見つけました。まだ導入できる目処は立っていないのですがある程度ノウハウ蓄積出来てきたのでここで検証内容等を記事にしようかと思っています。 Sysdig は幾つかのサービスが存在するのですが今回検証したのは Sysdig Serverless Security と呼ばれるモノで ECS Fargate 上のコンテナランタイムセキュリティを実践することができるサービスです。 Sysdig とは AWS のサービスにも脅威検知を行うことができるサービスが揃っているのはご存知と思います 対象 目的 技術・サービス AWS リソース 驚異検知 AWS GuardDuty また予防の観点で脆弱性診断が出来るサービスもありあす 対象 目的 技術・サービス AWS リソース セキュリティ診断 AWS Trusted Advisor ECS コンテナ 脆弱性診断 ECR Image Scan EC2 上のソフトウェア 脆弱性診断 AWS Inspector ここで気がつくと思うのですがコンテナ上の驚異検知を行うサービスが AWS には無いと思っています。 (2022/09 時点) Sysdig Serverless Security は ECS Fargate コンテナ上の脅威検知を行うサービスです。ECS Fargate 利用時にコンテナ上の脅威検知を行うサービスは他にも幾つかありますが、Sysdig はシステムコールを利用したコンテナランタイムセキュリティを実践して脅威検知・通知が行えるものになります。自分も詳しくないのですがこれを CWPP (Cloud Workload Protection Platform) と言うらしいです。ワークロードというのはクラウド上の仮想マシン・稼働中のソフトウェアを指して、CWPP はマルウェア保護、脆弱性スキャン、アクセス制御、異常検知の機能を使用してそれぞれのワークロードを保護する、ということらしいです。 ...

こんにちは @jedipunkz 🚀 です。 今回は CNCF にジョインした PipeCD と Datadog を用いて ECS 環境にてプログレッシブデリバリーを実現する方法について調査したので、その内容を記したいと思います。 そもそもプログレッシブデリバリーとは アプリケーションのデリバリー方法はカナリーリリースやブルーグリーンデプロイメント等がよく知られていると思います。プログレッシブデリバリーはその一歩先を行くデリバリー方式で、Prometheus や Datadog 等のメトリクスを用いて SLO (SRE の SLO と言うよりはデプロイのための指標という意味での) を元にカナリーリリースしたアプリケーションが期待した動作をしているかを確認し (プログレッシブデリバリー的にはこのフェーズを ANALYSIS という様です)、その上でカナリーリリースを完了するというフローになります。 構成 Pipecd, Piped 共に Kubernetes (EKS) クラスタ上に起動する構成 この検証ではこちらの構成を選択しました。この構成の特徴は piped は pipecd の API エンドポイントを指し示す pipecd は UI を提供 pipecd は Filestore (S3, GCS, Minio など), Datastore (MySQL, Firestore など) を利用可 (今回は Minio, MySQL を選択) piped は Target Group, ECS タスク定義等の操作を行うため ECS API へのアクセス権限が必要 piped の pipeline 上のステージで ANALYSIS という Datadog 等のメトリクスを解析する機能を有している アプリケーションレポジトリには app.pipecd.yaml を配置しターゲットグループ・タスク定義・ECS サービスを指し示す piped は GitHub レポジトリを参照 となっています。 ...

こんにちは。jedipunkz🚀 です。 引き続き Go を学習しています。前回の記事 ECS コンテナにログインする CLI を Go 言語で作った話 のまとめにも記したのですが Go のコードを書くアイデアとして下記をぼんやり考えていました。 ECR 脆弱性スキャンのパッケージを開発 そのパッケージを利用して Datadog のカスタムメトリクスとして送信 同様にそのパッケージを利用して ECR スキャンの CLI を作成 その紹介を軽くしたいと思います。 開発した ECR 脆弱性スキャンの Go パッケージ 開発したパッケージは https://github.com/jedipunkz/ecrscan になります。 下記のように Ecr 構造体を初期化します。 e := myecr.Ecr{} e.Repositories = [][]string{ {"image-to-scan", "latest"}, } e.Resion = "ap-northeast-1" finding, vulFindings, _ := e.ListFindings() その後 ListFindings() メソッドでスキャンします。結果、finding.FindingSeverityCounts には下記の深刻度毎のイメージに含まれている脆弱性の数が入ります。 INFORMATIONAL LOW MEDIUM HIGH CRITICAL UNDEFINED また、vulFindings には含まれている脆弱性の CVE 名 深刻度レベル (INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL, UNDEFINED) CVE URI 説明 が入ります。 CLI の開発 このパッケージを利用して開発したのが https://github.com/jedipunkz/evs という CLI です。利用方法は下記のように --image でイメージとタグを指定、--region でリージョンを指定して実行するだけです。 ...

こんにちは @jedipunkz 🚀 です。 今回は Go 言語で ECS コンテナにログインする CLI を作った話を書きます。 開発の経緯 自分はまだ Go 言語の初学者で学習のために開発するアイデアを探していた状態でした。そこで自分の勤めている会社で ECS Execute 機能を使ったコンテナログインの機能を開発者に提供していた事を思い出し色々調べていて「もう少し手間が省けないか？」と思い立った、という経緯で開発をはじめました。 awscli を使った ECS Execute 機能によるコンテナログイン 手間が多いと書きましたが実際に awscli を使う場合どの程度の手間があるのか簡単に記します。まず下記のコマンドを実行して $ aws ecs list-tasks --cluster <クラスタ名> --service <サービス名> taskArn が得られるので Arn から task ID を拾って、その task ID を使って $ aws ecs execute --cluster <クラスタ名> \ --task <task ID> \ -- container <コンテナ名> \ --interfactive \ --command "sh" とコマンドを実行することでコンテナにログイン出来ます。が手間が少し多いのと task ID を拾い出す作業も辛いので改善したい…。 操作画面 ということで miniecs という CLI を作ったのですが、 まずは操作している様子を貼り付けます。😷 Fuzzy Finder なインクリメンタルサーチが出来る CLI になっていて、ECS クラスタ名・ECS サービス名・コンテナ名を一部入力するとログインしたい環境が選択出来るツールになっています。 ...