OCI DevOps と ArgoCD/Flux を活用した GitOps CI/CD パイプライン構築ガイド

Contents

1 1️⃣ 全体アーキテクチャとデータフロー
2 2️⃣ CI 構築 – OCI DevOps と GitHub Actions の連携
3 3️⃣ GitOps ツール比較 – ArgoCD vs Flux
4 4️⃣ 環境別マニフェスト管理 – Helm ＆ Kustomize ハイブリッド
5 5️⃣ ブランチ戦略とデプロイフロー（Git Flow）
- 5.1 5‑1. Git Flow の全体像
- 5.2 5‑2. CI/CD 設定例（GitHub Actions）
6 6️⃣ ロールバックとプロモーションの実装例
7 7️⃣ 監視・ログ集約のベストプラクティス
- 7.1 7‑1. Prometheus ServiceMonitor 例
- 7.2 7‑2. OpenTelemetry Collector デプロイ例
8 8️⃣ 参考リンク（公式ドキュメント）
- 8.1 まとめ

スポンサードリンク

1️⃣ 全体アーキテクチャとデータフロー

flowchart LR
    subgraph SCM[GitHub]
        A[コード&lt;br/&gt;PR] --&gt; B[GitHub Actions]
    end
    subgraph CI[OCI DevOps Pipeline]
        B --&gt; C{ビルド &amp; スキャン}
        C --&gt; D[Buildah コンテナイメージ作成]
        C --&gt; E[Trivy 脆弱性スキャン]
        D --&gt; F[OCI Container Registry]
    end
    subgraph CD[ArgoCD]
        F --&gt; G[Helm + Kustomize 渡し]
        G --&gt; H[Sync to OKE / 他K8s]
    end

    style SCM fill:#f0f8ff,stroke:#333
    style CI  fill:#e6ffe6,stroke:#333
    style CD  fill:#fff4e6,stroke:#333

flowchart LR

subgraph SCM[GitHub]

A[コード<br/>PR] --> B[GitHub Actions]

end

subgraph CI[OCI DevOps Pipeline]

B --> C{ビルド & スキャン}

C --> D[Buildah コンテナイメージ作成]

C --> E[Trivy 脆弱性スキャン]

D --> F[OCI Container Registry]

end

subgraph CD[ArgoCD]

F --> G[Helm + Kustomize 渡し]

G --> H[Sync to OKE / 他K8s]

end

style SCM fill:#f0f8ff,stroke:#333

style CI fill:#e6ffe6,stroke:#333

style CD fill:#fff4e6,stroke:#333

コード管理：GitHub（Pull Request + ブランチ保護）。
CI：OCI DevOps のカスタムステップで Buildah を実行し、同一パイプライン内で Trivy スキャンを走らせる。
レジストリ：OCI Container Registry（IAM ポリシーで細粒度アクセス制御）。公式に高速転送が保証されていることはOracle のネットワークベンチマークで確認できる。
デプロイ：ArgoCD が Git リポジトリの overlays/* を監視し、Kubernetes（OKE など）へ自動同期。

2️⃣ CI 構築 – OCI DevOps と GitHub Actions の連携

2‑1. Buildah を OCI DevOps で利用する方法

OCI DevOps が ビルトイン で buildah ステップを提供しているわけではない（2024‑04 時点）。以下のいずれかで実装できる。

方法	メリット	実装概要
カスタム Docker コンテナ (OCI DevOps の「Custom Build」ステップ)	完全に自己管理でき、OCI CLI との認証情報共有が容易	`Dockerfile` に `buildah` をインストールし、ビルドステージで実行
GitHub Actions → OCI DevOps Trigger	GitHub 側の UI が統一できる	GitHub Actions から OCI DevOps の REST API (`pipelineRun`) を呼び出し、同様に `buildah` コンテナを走らせる

カスタムコンテナ例（Dockerfile）

FROM oraclelinux:8-slim

# 必要パッケージ
RUN microdnf install -y buildah git &amp;&amp; \
    microdnf clean all

ENTRYPOINT [&quot;/usr/bin/buildah&quot;]

FROM oraclelinux:8-slim

# 必要パッケージ

RUN microdnf install -y buildah git && \

microdnf clean all

ENTRYPOINT ["/usr/bin/buildah"]

OCI DevOps パイプライン定義（YAML）

version: 1.0
steps:
  - name: Build image with Buildah
    type: CustomBuild          # カスタム Docker イメージを指定
    image: myregistry.example.com/buildah:latest
    script: |
      buildah bud -t ${OCI_REGISTRY}/myapp:${COMMIT_SHA} .
      buildah push ${OCI_REGISTRY}/myapp:${COMMIT_SHA}
  - name: Trivy scan
    type: Trivy               # OCI DevOps が提供する標準ステップ
    image: aquasec/trivy:latest
    args:
      - image=${OCI_REGISTRY}/myapp:${COMMIT_SHA}
      - --severity=HIGH,CRITICAL

version: 1.0

steps:

- name: Build image with Buildah

type: CustomBuild # カスタム Docker イメージを指定

image: myregistry.example.com/buildah:latest

script: |

buildah bud -t ${OCI_REGISTRY}/myapp:${COMMIT_SHA} .

buildah push ${OCI_REGISTRY}/myapp:${COMMIT_SHA}

- name: Trivy scan

type: Trivy # OCI DevOps が提供する標準ステップ

image: aquasec/trivy:latest

args:

- image=${OCI_REGISTRY}/myapp:${COMMIT_SHA}

- --severity=HIGH,CRITICAL

ポイント：OCI_DEVOPS の認証は oci config file で自動マウントされ、IAM ポリシーに基づくシークレット管理が実現します（公式参照: OCI DevOps – Authentication）。

2‑2. GitHub Actions からの呼び出し例

name: CI (trigger OCI DevOps)

on:
  push:
    branches: [ develop ]

jobs:
  trigger-devops:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up OCI CLI
        uses: oracle-actions/setup-oci-cli@v2
        with:
          api_key_secret_name: OCI_API_KEY

      - name: Invoke OCI DevOps pipeline
        run: |
          oci devops build-run create \
            --pipeline-id ${{ secrets.DEVOPS_PIPELINE_OCID }} \
            --display-name &quot;GitHub CI ${GITHUB_SHA}&quot; \
            --freeform-tags Project=MyApp,Commit=${GITHUB_SHA}

on:

push:

branches: [ develop ]

jobs:

trigger-devops:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Set up OCI CLI

uses: oracle-actions/setup-oci-cli@v2

with:

api_key_secret_name: OCI_API_KEY

- name: Invoke OCI DevOps pipeline

run: |

oci devops build-run create \

--pipeline-id ${{ secrets.DEVOPS_PIPELINE_OCID }} \

--display-name "GitHub CI ${GITHUB_SHA}" \

--freeform-tags Project=MyApp,Commit=${GITHUB_SHA}

2‑3. Trivy スキャン（OCI DevOps 標準ステップ）

- name: Trivy scan
  type: Trivy
  image: aquasec/trivy:latest
  args:
    - ${OCI_REGISTRY}/myapp:${COMMIT_SHA}
    - --severity=HIGH,CRITICAL
    - --exit-code=1

- name: Trivy scan

type: Trivy

image: aquasec/trivy:latest

args:

- ${OCI_REGISTRY}/myapp:${COMMIT_SHA}

- --severity=HIGH,CRITICAL

- --exit-code=1

3️⃣ GitOps ツール比較 – ArgoCD vs Flux

項目	ArgoCD	Flux (v2)
同期方式	Pull‑based、手動/自動切替可能 (`syncPolicy.automated`)	完全自動（CRD 変更→即適用）
UI	Web コンソールが充実、ロールバック UI がある	主に CLI／GitHub Actions, UI は外部ツール (Weave GitOps)
プラグイン/拡張性	SSO、OPA、カスタムヘルスチェック多数	コンポーネント単位で細かく分離、Kustomize/Helm 直接組み込み
運用負荷	初期設定はやや手間だが可視化が高い	設定ファイル中心でコードレビューに統合しやすい
推奨シーン	UI で状況把握したい運用チーム、マルチクラスタ管理	インフラ全体をコード化し CI と完全統合したい組織

結論：本稿では UI の利便性とロールバック手順の明示が必要なため ArgoCD をベースに実装例を示す。Flux は別章で簡易構成を提示する。

4️⃣ 環境別マニフェスト管理 – Helm ＆ Kustomize ハイブリッド

4‑1. Helm Chart のベース化

myapp/
├─ Chart.yaml
├─ values.yaml            # デフォルト
├─ templates/
│   ├─ deployment.yaml
│   └─ service.yaml
└─ charts/                # 依存チャート (例: redis)

myapp/

├─ Chart.yaml

├─ values.yaml # デフォルト

├─ templates/

│ ├─ deployment.yaml

│ └─ service.yaml

└─ charts/ # 依存チャート (例: redis)

values‑dev.yaml, values‑prod.yaml を作成し、CI 時に --values 指定。
公式リファレンス：https://helm.sh/docs/topics/charts/

4‑2. Kustomize overlay による環境差分

overlays/
├─ dev/
│   ├─ kustomization.yaml
│   └─ patch-replicas.yaml
└─ prod/
    ├─ kustomization.yaml
    └─ patch-resources.yaml

overlays/

├─ dev/

│ ├─ kustomization.yaml

│ └─ patch-replicas.yaml

└─ prod/

├─ kustomization.yaml

└─ patch-resources.yaml

`overlays/dev/kustomization.yaml`（例）

resources:
  - ../../myapp
patchesStrategicMerge:
  - patch-replicas.yaml
configMapGenerator:
  - name: app-config
    files:
      - config/dev.env

resources:

- ../../myapp

patchesStrategicMerge:

- patch-replicas.yaml

configMapGenerator:

- name: app-config

files:

- config/dev.env

4‑3. CI パイプラインでの Helm + Kustomize 実行フロー

# .github/workflows/deploy.yml
name: Deploy (ArgoCD)

on:
  push:
    branches: [ develop, main ]

jobs:
  render-and-sync:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Render Helm chart
        run: |
          helm template myapp \
            -f values-${{ env.ENV }}.yaml &gt; rendered.yaml

      - name: Apply Kustomize overlay
        run: |
          kustomize build overlays/${{ env.ENV }} | \
          kubectl apply -f -

      - name: Sync ArgoCD app
        env:
          ARGOCD_SERVER: ${{ secrets.ARGOCD_SERVER }}
          ARGOCD_TOKEN:  ${{ secrets.ARGOCD_TOKEN }}
        run: |
          argocd login $ARGOCD_SERVER --auth-token $ARGOCD_TOKEN --insecure
          argocd app sync myapp-${{ env.ENV }}

# .github/workflows/deploy.yml

on:

push:

branches: [ develop, main ]

jobs:

render-and-sync:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Render Helm chart

run: |

helm template myapp \

-f values-${{ env.ENV }}.yaml > rendered.yaml

- name: Apply Kustomize overlay

run: |

kustomize build overlays/${{ env.ENV }} | \

kubectl apply -f -

- name: Sync ArgoCD app

env:

ARGOCD_SERVER: ${{ secrets.ARGOCD_SERVER }}

ARGOCD_TOKEN: ${{ secrets.ARGOCD_TOKEN }}

run: |

argocd login $ARGOCD_SERVER --auth-token $ARGOCD_TOKEN --insecure

argocd app sync myapp-${{ env.ENV }}

ポイント：helm template はイメージタグだけを置換し、実体は Kustomize が上書きするため、環境ごとの差分が明確になる。

5️⃣ ブランチ戦略とデプロイフロー（Git Flow）

5‑1. Git Flow の全体像

gitGraph
    commit tag: &quot;v0.1.0&quot;
    branch develop
    checkout develop
    commit id: &quot;feature A&quot;
    branch feature/awesome
    checkout feature/awesome
    commit id: &quot;実装&quot;
    checkout develop
    merge feature/awesome tag: &quot;v0.2.0‑rc&quot;
    branch release/v1.0.0
    checkout release/v1.0.0
    commit id: &quot;リリース準備&quot;
    checkout main
    merge release/v1.0.0 tag: &quot;v1.0.0&quot;
    branch hotfix/critical
    checkout hotfix/critical
    commit id: &quot;緊急修正&quot;
    checkout main
    merge hotfix/critical

gitGraph

commit tag: "v0.1.0"

branch develop

checkout develop

commit id: "feature A"

branch feature/awesome

checkout feature/awesome

commit id: "実装"

checkout develop

merge feature/awesome tag: "v0.2.0‑rc"

branch release/v1.0.0

checkout release/v1.0.0

commit id: "リリース準備"

checkout main

merge release/v1.0.0 tag: "v1.0.0"

branch hotfix/critical

checkout hotfix/critical

commit id: "緊急修正"

checkout main

merge hotfix/critical

main：本番環境（prod overlay）へデプロイ。タグ (vX.Y.Z) が付くと自動で本番プロモーションが走る。
develop：ステージング環境（dev overlay）に同期。プルリクエストマージ時に CI が実行され、ArgoCD が myapp-dev を更新。
release/*：リリース候補ブランチ。必要に応じて手動レビュー後、本番へマージ。
hotfix/*：本番緊急修正。マージと同時に main から develop へチェリーピック。

5‑2. CI/CD 設定例（GitHub Actions）

name: CI/CD (GitFlow)

on:
  push:
    branches:
      - develop          # ステージング自動デプロイ
      - main             # 本番プロモーション（タグ付き）
    tags:
      - 'v*.*.*'         # タグが付いたら本番デプロイ

jobs:
  build-and-test:
    uses: ./.github/workflows/ci.yml   # 前述の Buildah / Trivy フロー
    secrets: inherit

  deploy-dev:
    if: github.ref == 'refs/heads/develop'
    needs: build-and-test
    runs-on: ubuntu-latest
    env:
      ENV: dev
    steps:
      - uses: ./.github/workflows/deploy.yml   # Helm+Kustomize + ArgoCD sync

  promote-prod:
    if: startsWith(github.ref, 'refs/tags/v')
    needs: build-and-test
    runs-on: ubuntu-latest
    env:
      ENV: prod
    steps:
      - uses: ./.github/workflows/deploy.yml

on:

push:

branches:

- develop # ステージング自動デプロイ

- main # 本番プロモーション（タグ付き）

tags:

- 'v*.*.*' # タグが付いたら本番デプロイ

jobs:

build-and-test:

uses: ./.github/workflows/ci.yml # 前述の Buildah / Trivy フロー

secrets: inherit

deploy-dev:

if: github.ref == 'refs/heads/develop'

needs: build-and-test

runs-on: ubuntu-latest

env:

ENV: dev

steps:

- uses: ./.github/workflows/deploy.yml # Helm+Kustomize + ArgoCD sync

promote-prod:

if: startsWith(github.ref, 'refs/tags/v')

needs: build-and-test

runs-on: ubuntu-latest

env:

ENV: prod

steps:

- uses: ./.github/workflows/deploy.yml

ポイント：ブランチ名とタグでデプロイ対象が自動的に切り替わるため、開発者は「コードを書いて PR をマージ」だけでフロー全体を完走できる。

6️⃣ ロールバックとプロモーションの実装例

6‑1. ArgoCD の正しいロールバック手順

ArgoCD は 自動ロールバック 用フィールド (rollback) を持たない。ロールバックは次のいずれかで実施する。

方法	説明
CLI 手動ロールバック	`argocd app rollback <APP> <REVISION>` で任意の Git コミットに戻す。
SyncOptions に `Prune=false` + `selfHeal=true`	デプロイ失敗時に自動で前回成功したマニフェストへ再同期させる（完全自動ではないが手作業を減らす）。
ArgoCD UI の「Rollback」ボタン	同様に対象リビジョンを選択して実行できる。

アプリケーションマニフェスト（自動 sync + self‑heal）

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-prod
spec:
  project: default
  source:
    repoURL: https://github.com/yourorg/myapp.git
    targetRevision: main            # 常に最新ブランチを指す
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: prod
  syncPolicy:
    automated:
      prune: true
      selfHeal: true               # デプロイ失敗時に自動で再同期
    retry:
      limit: 5
      backoff:
        duration: 10s
        factor: 2

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

spec:

project: default

source:

repoURL: https://github.com/yourorg/myapp.git

targetRevision: main # 常に最新ブランチを指す

path: overlays/prod

destination:

server: https://kubernetes.default.svc

namespace: prod

syncPolicy:

automated:

prune: true

selfHeal: true # デプロイ失敗時に自動で再同期

retry:

limit: 5

backoff:

duration: 10s

factor: 2

手順：デプロイが失敗したら UI/CLI の「Rollback」ボタンで対象リビジョン（例: 前回のタグ）を選択し実行。自動 selfHeal が有効な場合、ArgoCD はすぐに前回成功状態へ復旧しようとする。

6‑2. 本番昇格（プロモーション）のベストプラクティス

イメージタグは immutable：CI 時点で sha256 ハッシュを付与し、リリース時に同一タグが再利用されないようにする。
Git タグによるデプロイトリガー：vX.Y.Z タグ作成 → GitHub Actions が prod overlay を ArgoCD に sync。
承認ワークフロー：workflow_dispatch または GitHub Environments の Required reviewers で手動承認を組み込む。

本番プロモーション用 GitHub Actions（タグ作成時）

name: Promote to Production

on:
  push:
    tags:
      - 'v*.*.*'

jobs:
  promote:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Sync ArgoCD prod app
        env:
          ARGOCD_SERVER: ${{ secrets.ARGOCD_SERVER }}
          ARGOCD_TOKEN:  ${{ secrets.ARGOCD_TOKEN }}
        run: |
          argocd login $ARGOCD_SERVER --auth-token $ARGOCD_TOKEN --insecure
          # タグ名そのものが Git のリビジョンになる
          argocd app sync myapp-prod --revision ${{ github.ref_name }}

on:

push:

tags:

- 'v*.*.*'

jobs:

promote:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Sync ArgoCD prod app

env:

ARGOCD_SERVER: ${{ secrets.ARGOCD_SERVER }}

ARGOCD_TOKEN: ${{ secrets.ARGOCD_TOKEN }}

run: |

argocd login $ARGOCD_SERVER --auth-token $ARGOCD_TOKEN --insecure

# タグ名そのものが Git のリビジョンになる

argocd app sync myapp-prod --revision ${{ github.ref_name }}

6‑3. Kubernetes 側の自己修復（Pod 再スケジューリング）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: web
          image: ${{ secrets.OCI_REGISTRY }}/myapp:${{ github.sha }}
          ports:
            - containerPort: 8080
      nodeSelector:
        kubernetes.io/arch: amd64   # 必要に応じて制約を追加

---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: myapp-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: myapp

apiVersion: apps/v1

kind: Deployment

metadata:

spec:

replicas: 3

selector:

matchLabels:

app: myapp

template:

metadata:

labels:

app: myapp

spec:

containers:

- name: web

image: ${{ secrets.OCI_REGISTRY }}/myapp:${{ github.sha }}

ports:

- containerPort: 8080

nodeSelector:

kubernetes.io/arch: amd64 # 必要に応じて制約を追加

---

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

spec:

minAvailable: 2

selector:

matchLabels:

app: myapp

PDB によりノード障害時でも最低 2 ポッドは残す。
NodeSelector / Tolerations を組み合わせて、特定の AZ/リージョンへ自動フェイルオーバーさせる。

7️⃣ 監視・ログ集約のベストプラクティス

カテゴリ	ツール	実装ポイント
メトリクス	Prometheus + Grafana	`ServiceMonitor` でアプリと ArgoCD の metrics を取得。Grafana ダッシュボードは公式 Kubernetes Cluster Monitoring テンプレートにカスタムメトリクス (`argocd_app_sync_total`) を追加。
分散トレース	OpenTelemetry Collector (OTel)	サイドカー方式で各 Pod に注入し、Trace と Log を統合的にバックエンド（例: OCI Logging Analytics）へ送信。
ログ集約	OCI Logging + Loki	Fluent Bit がコンテナ stdout/stderr を OCI Logging へ転送、Loki が Grafana で可視化。
CI/CD ヘルス	ArgoCD & Flux metrics	Prometheus の `scrape_configs` に ArgoCD/Flux エンドポイントを追加し、デプロイ遅延・失敗率をモニタリング。

7‑1. Prometheus ServiceMonitor 例

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: myapp-monitor
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
    - port: metrics
      interval: 30s

apiVersion: monitoring.coreos.com/v1

kind: ServiceMonitor

metadata:

spec:

selector:

matchLabels:

app: myapp

endpoints:

- port: metrics

interval: 30s

7‑2. OpenTelemetry Collector デプロイ例

apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otel-collector
spec:
  config: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    exporters:
      logging:
      otlphttp:
        endpoint: &quot;https://logging.example.com/otlp&quot;
    service:
      pipelines:
        traces:
          receivers: [otlp]
          exporters: [logging, otlphttp]

apiVersion: opentelemetry.io/v1alpha1

kind: OpenTelemetryCollector

metadata:

spec:

config: |

receivers:

otlp:

protocols:

grpc:

http:

exporters:

logging:

otlphttp:

endpoint: "https://logging.example.com/otlp"

service:

pipelines:

traces:

receivers: [otlp]

exporters: [logging, otlphttp]

公式情報：OpenTelemetry on OCI – https://docs.oracle.com/en-us/iaas/Content/OpenTelemetry/home.htm

8️⃣ 参考リンク（公式ドキュメント）

項目	リンク
OCI DevOps – パイプライン & 認証	https://docs.oracle.com/en-us/iaas/devops/
Buildah Docker イメージ例	https://hub.docker.com/r/oraclelinux/buildah
Trivy 公式アクション	https://github.com/aquasecurity/trivy-action
ArgoCD – アプリケーションマニフェスト & ロールバック手順	https://argo-cd.readthedocs.io/en/stable/user-guide/rollback/
Flux v2 – GitOps Toolkit	https://fluxcd.io/docs/components/
Helm – Chart Best Practices	https://helm.sh/docs/topics/charts/
Kustomize – Overlays Guide	https://kubectl.docs.kubernetes.io/references/kustomize/
Prometheus Operator – ServiceMonitor	https://github.com/prometheus-operator/prometheus-operator
OpenTelemetry on OCI	https://docs.oracle.com/en-us/iaas/Content/OpenTelemetry/home.htm

まとめ

CI は OCI DevOps のカスタム Buildah コンテナと Trivy スキャンで構成し、認証は IAM に委譲。
GitFlow + GitHub Actions がブランチ・タグ駆動の自動デプロイを実現し、develop → staging、tag → production のフローが明快。
ArgoCD は UI と手動ロールバック機能で運用性を確保しつつ、selfHeal による自動復旧も併用可能。
Helm + Kustomize ハイブリッドにより、共通チャートと環境差分の管理がシンプルかつ拡張性高くなる。
可観測性 は Prometheus/Grafana・OpenTelemetry・OCI Logging の三層でカバーし、CI/CD とランタイム双方を一元的に監視できる。

この構成をそのまま OCI の無料ティアやエンタープライズプランへ適用すれば、スケーラブルかつ安全な GitOps パイプライン が数分で稼働します。ぜひご自身のプロジェクトに合わせてカスタマイズしてみてください。

スポンサードリンク

OCI DevOps と ArgoCD/Flux を活用した GitOps CI/CD パイプライン構築ガイド

1️⃣ 全体アーキテクチャとデータフロー

2️⃣ CI 構築 – OCI DevOps と GitHub Actions の連携

2‑1. Buildah を OCI DevOps で利用する方法

カスタムコンテナ例（Dockerfile）

OCI DevOps パイプライン定義（YAML）

2‑2. GitHub Actions からの呼び出し例

2‑3. Trivy スキャン（OCI DevOps 標準ステップ）

3️⃣ GitOps ツール比較 – ArgoCD vs Flux

4️⃣ 環境別マニフェスト管理 – Helm ＆ Kustomize ハイブリッド

4‑1. Helm Chart のベース化

4‑2. Kustomize overlay による環境差分

overlays/dev/kustomization.yaml（例）

4‑3. CI パイプラインでの Helm + Kustomize 実行フロー

5️⃣ ブランチ戦略とデプロイフロー（Git Flow）

5‑1. Git Flow の全体像

5‑2. CI/CD 設定例（GitHub Actions）

6️⃣ ロールバックとプロモーションの実装例

6‑1. ArgoCD の正しいロールバック手順

アプリケーションマニフェスト（自動 sync + self‑heal）

6‑2. 本番昇格（プロモーション）のベストプラクティス

本番プロモーション用 GitHub Actions（タグ作成時）

6‑3. Kubernetes 側の自己修復（Pod 再スケジューリング）

7️⃣ 監視・ログ集約のベストプラクティス

7‑1. Prometheus ServiceMonitor 例

7‑2. OpenTelemetry Collector デプロイ例

8️⃣ 参考リンク（公式ドキュメント）

まとめ

2️⃣ CI 構築 – OCI DevOps と GitHub Actions の連携

2‑1. Buildah を OCI DevOps で利用する方法

OCI DevOps パイプライン定義（YAML）

2‑3. Trivy スキャン（OCI DevOps 標準ステップ）

`overlays/dev/kustomization.yaml`（例）

4‑3. CI パイプラインでの Helm + Kustomize 実行フロー

5️⃣ ブランチ戦略とデプロイフロー（Git Flow）

5‑1. Git Flow の全体像