すべてのカテゴリ

CI/CDは便利そうだからとりあえず導入する、というケースもありますが、実は「タイミング」が重要です。今回は、導入を検討すべき3つの基準を紹介します。【① 手動デプロイが増えてきた】・毎回サーバーにSSHして更新している・作業手順が属人化している・デプロイミスが起きたことがあるこの状態なら導入タイミングです。自動化することでヒューマンエラーを減らし、作業時間も短縮できます。【② チーム開発になった】個人開発では問題なくても、複数人になると品質管理が重要になります。CIを入れることで：・プッシュ時の自動テスト・ビルドチェック・品質の一定化が可能になります。【③ 本番環境の更新頻度が上がった】機能追加や改善が増えてくると、手動運用では限界がきます。CDを導入すれば：・ビルド・イメージ作成・デプロイまでを自動化できます。CI/CDは「最初から入れるべきもの」ではなく、「必要になったら入れるもの」です。ただし、設計段階で将来的な導入を想定しておくと、後からの移行がスムーズになります。今後もLinux / Docker / CI/CDに関する実践的な内容を発信していきます。

EKSを運用していると、必ずここで悩みます。ノードを多めに用意すれば安心ですが、使っていない時間の料金が積み上がります。かといって減らすと、Podがスケジュールできずに詰まります。この「多すぎ」と「足りない」の間を自動で埋めるのが Karpenter です。AWSが公開しているオープンソースのオートスケーラで、必要になった瞬間に必要な分だけEC2を起動し、要らなくなったら削除します。この記事は、すでに稼働しているEKSクラスタに後から Karpenter を追加した際の作業メモです。■ 導入すると何が変わるかやることは2つだけです。・Podがスケジュールできない状態になったら、ノードを新しく起動する・そのノードが空になったら、自動で削除するシンプルですが、この2つが自動で回るかどうかで、月末の請求額はかなり変わります。■ 事前に用意するもの以下の4つを先に入れておきます。どれか欠けると途中で止まります。・AWS CLI … AWSの操作全般・kubectl … Kubernetesの操作・eksctl … EKS専用のCLI・helm … Kubernetesのパッケージ管理Karpenter は自分でEC2を起動するため、AWS側の権限が必要になります。その権限の渡し方が IRSA、正式には IAM Roles for Service Accounts という仕組みです。ざっくり言うと、KubernetesのサービスアカウントにIAMロールを紐づけて、アクセスキーを書かずに権限を渡す方式です。認証情報をファイルに直書きしなくて済むので、これを使います。■ 手順

人工知能（AI）は、コンピューターが人間と同様のような思考や行動を行うことを可能にする技術です。AIは、明らかなタスクや課題を効率的に実行したり、新しいタスクを学習したり、複雑な状況を分析して最適な行動を取ったりすることができます。