LoginSignup
0
0
@tatsuya11bbs(Tatsuya)

【CICD】AWS Codeシリーズまとめ

Last updated at Posted at 2024-07-26

はじめに

AWSでCI/CDの活用を考え始めると、Codeシリーズを利用します。最近IC/CD周りを整備する機会があったので備忘として残しておきます。

CodeCommit

  • 概要

    • レジストリサイズの上限なし
    • プルリクエスト機能に対応
    • VPCエンドポイント対応
    • GitオブジェクトはS3で管理され、GitインデックスはDynamoDBで管理

  • 接続方法

    • IAMでGitユーザー名とパスワードを生成
      • IAMのユーザーのところから　ユーザー>セキュリティ認証情報 >AWS CodeCommit の HTTPS Git 認証情報 を取得
      • git clone した際の username, passwordとして使う
    • SSH接続 (IAMとSSHキーを紐付ける)
    • git-remote-codecommit (IAMのcredencials)
    • 開発ツールからの接続 (AWS Toolkit利用)

  • コミット履歴の表示

    • git rebaseコマンドでリベースを行った場合は、リポジトリの履歴が変更されるので注意
    • ブランチやタグを切り替えて表示可能
    • 直前のコミットとの差分比較
    • Commit IDをコピー可能

  • プルリクの作成

    • プルリク = リポジトリのユーザに対する作業内容の通知

    • プルリクを起点として、議論やコミュニケーション機会を提供

    • コードレビューや変更箇所の精査ができ、品質改善につながる

    • ターゲットブランチとソースブランチを選択して作成 (タイトルと説明を入力)

    • プルリクのマージ

      • fast-forward (早送りマージ)
        • git merge --ff-only
        • ブランチをマージし、送信先ブランチポインタを送信元ブランチの先端に移動
        • gitで言うデフォルトのマージ戦略
      • 3-way merge
        • git merge --no-ff
        • マージコミットを作成し、個々のソースコミットをターゲットブランチへ追加
      • Squash merge (スカッシュしてマージ)
        • git merge --squash
        • ソースブランチから全てのコミットをターゲットブランチで1つのマージコミットに結合

    • プルリクの承認ルールワークフロー

      • コードをマージする前に満たなさければならないルール要件を定義し、高品質のコード変更のみがマージされるようにすることに役立つ

    • ブランチレベルのアクセスを許可

      • リポジトリを変更できるユーザーの制御だけでなく、リポジトリ内のブランチを変更できるユーザを制御可能
      • IAM PolicyのCondition句でブランチを絞れる
      • 開発チーム以外にはプルリクをmasterブランチへマージさせないなど、ブランチへのアクセスを柔軟に制御

  • VPC Endpoint

    • Git操作用とCodeCommit API操作用の2種類

CodeArtifact

  • 概要
    • セキュアでスケーラブルなマネージドアーティファクト管理
    • Maven、Gradle、npm、yarn、twine、pipなどの一般的なビルドツール、パッケージマネージャーから利用可能

CodeBuild

  • 基本的にビルドするサービス

  • ECRとDockerにログインし、Dockerビルド、タグをつけてECRにPUSHするところまでやる

  • コンソール

    • 環境
      • プロビジョニングモデル(オンデマンド/リザーブドキャパシティ)
      • 環境イメージ (マネージド型イメージ/カスタムイメージ)
      • コンピューティング(EC2/Lambda)
      • OS
      • ランタイム
      • イメージ
      • イメージのバージョン
      • GPU強化コンピューティング
      • サービスロール
      • 追加設定
        • タイムアウト
        • キュータイムアウト
        • 特権付与
        • レポート自動検出
        • 証明書
        • VPC

  • ビルドバッチ

    • 埋め込み可能なイメージ(バッチ)として動的に生成されるステータス画像
    • ビルドプロジェクトに対して生成されるパブリック可能なURLで認証不要

  • VPC内リソースへのアクセス

    • プライベートサブネット内のリソースへアクセス
    • VPCエンドポイントをサポート
.json
version: 0.2
env:
  variables:
    AWS_DEFAULT_REGION: "ap-northeast-1"
    DOCKER_USER: AWS
    REPOSITORY_URI: "<ECRのURIをコピーする>"
    DOCKERHUB_PASS: "<Docker Password>"
    DOCKERHUB_USER: "<Docker User Name>"
# phasesにはあとinstallがある
phases:
  pre_build:
    commands:
      - echo "ECRへログイン"
      - aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws/g4f7s3b3
      - echo Logging in to Docker Hub...
      - echo $DOCKERHUB_PASS | docker login -u $DOCKERHUB_USER --password-stdin
  build:
    commands:
      - echo "ビルド開始"
      - docker build -t codebuild-app .
      - docker tag codebuild-app:latest public.ecr.aws/XXXXXXXX/codebuild-app:latest
  post_build:
    commands:
      - echo "ECRへpush"
      - docker push public.ecr.aws/XXXXXXXXX/codebuild-app:latest
  • Docker Loginが上手くいかないこともあるのでその際は下記の対応を行う

  • docker loginは別でかく
  • 匿名でログインするのでエラーになる可能性あり
  • また、Deployまでするならイメージの詳細をartifactとして出力する
  • この情報がCodeDeployをする際に必要
  post_build:
    commands:
      - docker push $REPOSITORY_URI:latest
      - docker push $REPOSITORY_URI:$IMAGE_TAG
      - printf '{"Version":"1.0","ImageURI":"%s"}' $REPOSITORY_URI:$IMAGE_TAG > imageDetail.json

artifacts:
 files: imageDetail.json


{
    "Version":"1.0",
    "ImageURI": "<DockerイメージのURI>"
}

  • このようにしておくことで、後ほど、CodeDeploy+ECSでのデプロイ時にtaskdef.json内でプレースホルダにしておいた部分が、ここでビルドしたイメージの情報で置き換えることができる

  • フォルダ構成のイメージ

image.png

CodeDeploy

  • デプロイの設定を行う
  • デプロイ先は下記対応
    • Lambda
    • EC2/オンプレ
    • ECS
  • 設定ファイル
    • appspecc.yml
      • デプロイ設定を規定するファイル
    • taskdef.json
      • ECSのタスク定義の内容を記載したファイル
      • CICD組んだらタスク定義で参照するイメージは毎回変わるので、taskdef.jsonの中でプレスホルダーを設定しておき、imageDetail.jsonで指定したURIに自動で置き換える
      • latestタグを使用している場合はこの仕組みはいらない。けど、latest運用はやめるべき
    • imageDetail.json
  • デプロイする時はBlue/Greenデプロイを採用することが多い
appsepc.yml
version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "TASK_DEFINITIONのARN"
        LoadBalancerInfo:
          ContainerName: "flask-app"
          ContainerPort: "80"

  • CodeDeployでECSにデプロイする際にテストポートを指定できる。これはALBのリスナーを余分に用意しているポートとは別ポートでデプロイした内容を確認するために使用

  • サービスを公開したまま別ポートで確認を行い、OKならトラフィックを新規タスクセットに切り替えることが簡単

  • サービスロール

    • 管理ポリシー
      • AWSCodeDeployRole
      • AWSCodeDeployRoleForLambda
      • AWSCodeDeployRoleForLambdaLimited
      • AWSCodeDeployRoleForECS
      • AWSCodeDeployRoleForECSLimited

  • ECSのデプロイ

    • アプリケーションの作成
      • アプリケーション名
      • コンピューティングプラットフォーム
    • デプロイグループの作成
      • デプロイグループ名
      • サービスロール
      • 環境設定
        • ECSクラスター名
        • ECSサービス名
      • Load balancer
        • Load balancerを選択
        • 本稼働リスナーポート
        • ターゲットグループ1
        • ターゲットグループ2
      • デプロイ設定
        • トラフィックの再ルーティング
          • すぐにトラフィックを再ルーティング
          • トラフィックを再ルーティングするタイミングを指定
      • デプロイ設定
        • CodeDeployDefault.ECSAllAtOnce
        • CodeDeployDefault.ECSLinear10PercentEvery1Minutes
      • 元のリビジョンの終了
        → 「デプロイグループの作成」

  • デプロイの作成

    • デプロイグループ
    • リビジョンタイプ
      • AppSpec エディタの使用
      • YAML
        →「デプロイの作成」

  • 注意事項

    • ECSのserviceの設定もB/Gでないとデプロイは上手くいかない (ローリングアップデートになっていないか確認)
    • ローリングアップデートを設定できるが、CodeDeployを使用せずECS機能でローリングアップデートしていることになる

  • VPCエンドポイントをサポート

    • EC2へのデプロイにはcodedeploy、codedeploy-commands-secureの両方が必要
    • Lambda/ECSへのデプロイにはcodedeployのみ必要

  • デプロイメントのためのコンテナイメージのタグ付け

    • Dockerタグはデプロイ時のみではなく個々のコンテナの開始時にも利用
    • latestやprodタグはスケールアウトイベント発生時に未テストのコードを本番環境にデプロイする結果を招く
    • デプロイメントにはユニークでイミュータブルなタグを利用すべき
    • イミュータブルなタグをデプロイ

CodeCatalyst

  • Amazon CodeCatalyst
    • 統合ソフトウェア開発サービス
      • マネージド
      • オールインワン
      • 統合されている
      • セキュリティ重視
      • フレキブル
    • Codeシリーズとの違い
      • 各種ツールを統合したマネージドサービス
      • すぐに利用開始できる
      • カスタムツールチェーンの構築よりもApp開発に集中できる
    • CodeCatalystの導入が効果的な場面
      • これからGitやCI/CDを使ったDevOpsの取り組みを始めたい
      • パイプラインの維持管理が大変
      • CI/CDパイプラインやIssue管理、Gitによるバージョン管理など、App開発に必要な構成一式をすぐに準備したい

image.png

  • 用語
    • Space
      • 部署、グループ、会社などの組織を表現する概念
      • 1つ以上のAWSアカウントと紐付ける
    • Project
      • リモート開発環境、Gitリモートリポジトリ、CI/CDパイプライン、Issue管理など、チーム開発に必要なコンポーネントがカプセル化されたコラボレーション空間
      • 空の状態で作成することも、Blueprintを利用して作成することも可能
    • Space/PJレベルでRolen伊夜ユーザーの権限管理が可能
    • Blueprint
      • アプリケーションコードやワークフロー、インフラの構成を定義したProjectのテンプレート
      • 種類
        • CodeCatalyst Blueprint
        • Custom Blueprint (Enterprise tierのみ)
    • Source repository
      • Project用のGitリモートリポジトリ
      • コードやアセットだけでなく、CI/CDパイプラインの設定などProjectに関する設定の保存先になる
      • Pull Request機能
    • Dev Environment
      • クラウド上のマネージドな開発環境
      • Cloud9、VSCode、JetBrains IDEsから接続して利用可能
      • Free tierから利用可能
    • Workflow
      • CICDにおけるビルド、テスト、デプロイの手順を定義して実行する機能
      • YAMLで記述
      • Report機能でビルドやテストの結果を出力し確認することが可能
      • VPC接続に対応
    • Issue
      • Project内の課題管理機能
      • 効率的に作業を追跡することが可能
        • カンバンボード
        • グリッド表示
      • CodeCatalyst内に作成、またはJiraと接続が可能
    • その他の機能
      • Search
      • Amazon Q in Amazon CodeCatalyst (preview)

終わりに

少し手が出しにくい領域でもありますが、CICD組めるのは大事ですのでしっかりと理解を深めていきたいと思います

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0