Argo CD のインストールと設定ガイド（kind・本番環境）

2026年6月24日

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

エンジニアの世界では、「いつでも動ける状態を作っておけ」とよく言われます。
技術やポートフォリオがあっても、自分に合う案件情報を日常的に見れていないと、いざ動こうと思った時に比較や判断が難しくなってしまいます。
普段から案件情報が集まる環境を作っておくと、良い案件が出た時にすぐ動きやすくなりますよ。
筆者自身も、メガベンチャー勤務時代に年収1,500万円を超えた経験があります。振り返ると、技術だけでなく「どんな案件や働き方があるか」を日頃から見ていたことが、キャリアの選択肢を広げるきっかけになりました。
このブログを読んでくれた方に感謝を込めて、実際に使っている情報収集サービスを紹介します。

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

Contents

1 前提条件とインストール環境
- 1.1 必要ツールと推奨バージョン
- 1.2 ローカル kind クラスタ作成
2 Argo CD の公式マニフェストによるインストール
3 UI と CLI の初期設定
4 GitHub 連携とサンプルアプリのデプロイ
5 本番環境への移行と高度なセキュリティ対策
6 まとめ

スポンサードリンク

前提条件とインストール環境

Argo CD のデプロイには Kubernetes クライアントとコンテナ実行基盤が必要です。ここでは推奨バージョンと、各ツールの取得方法を最新リリースに合わせて記載します。

必要ツールと推奨バージョン

ツール	推奨バージョン (2026年時点)	インストール例
kubectl	v1.28 以上	`curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"`
Docker	Engine 24.x 系列	Docker Desktop の公式サイトからインストーラを取得
kind	v0.22.0 以上	`GO111MODULE=on go install sigs.k8s.io/kind@v0.22.0`

macOS、Linux、Windows（WSL2）それぞれ上記コマンドを実行すればインストール完了です。

ローカル kind クラスタ作成

ローカル環境で Argo CD を試すための最小構成クラスタを作ります。以下は 設定ファイル作成 → クラスタ生成 → 動作確認 の流れです。

# 1. 任意の設定ファイル (kind-config.yaml) を用意
cat &lt;&lt;'EOF' &gt; kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  extraPortMappings:
  - containerPort: 30080   # Argo CD UI 用ポート例
    hostPort: 8080
EOF

# 2. クラスタ作成
kind create cluster --name argo-demo --config kind-config.yaml

# 3. ノードの状態確認（Ready が出れば OK）
kubectl get nodes

# 1. 任意の設定ファイル (kind-config.yaml) を用意

cat <<'EOF' > kind-config.yaml

kind: Cluster

apiVersion: kind.x-k8s.io/v1alpha4

nodes:

- role: control-plane

extraPortMappings:

- containerPort: 30080 # Argo CD UI 用ポート例

hostPort: 8080

EOF

# 2. クラスタ作成

kind create cluster --name argo-demo --config kind-config.yaml

# 3. ノードの状態確認（Ready が出れば OK）

kubectl get nodes

kubectl get nodes が Ready を示せば、以降の手順はすべてこのローカルクラスタ上で実行できます。

Argo CD の公式マニフェストによるインストール

Argo CD は公式リポジトリから提供される install.yaml ひとつで全コンポーネントをデプロイできます。ここでは「最新安定版タグを取得」する方法と、バージョン固定の落とし穴について解説します。

Namespace 作成とマニフェスト適用

# 1. Argo CD 用 namespace の作成
kubectl create namespace argocd

# 2. ダウンロードした install.yaml を適用（-n argocd は省略可だが明示的に書くのがベストプラクティス）
kubectl apply -f install.yaml -n argocd

# 1. Argo CD 用 namespace の作成

kubectl create namespace argocd

# 2. ダウンロードした install.yaml を適用（-n argocd は省略可だが明示的に書くのがベストプラクティス）

kubectl apply -f install.yaml -n argocd

デプロイ結果の確認

kubectl get pods -n argocd

1 2	kubectl get pods -n argocd

コンテナ名	推奨稼働状態
`argocd-server`	Running
`argocd-repo-server`	Running
`argocd-application-controller`	Running
`argocd-dex-server` (任意)	Running

すべて Running かつ READY=1/1 が確認できればインストールは成功です。

UI と CLI の初期設定

Argo CD は Web UI と argocd CLI の二本柱で操作します。本節では安全に管理者パスワードを取得し、TLS 設定が不完全な環境での --insecure 使用リスクと代替手段についても触れます。

Port‑Forward による UI アクセス

kubectl -n argocd port-forward svc/argocd-server 8080:443

1 2	kubectl -n argocd port-forward svc/argocd-server 8080:443

ブラウザで https://localhost:8080 にアクセスするとログイン画面が表示され、自己署名証明書の警告は 無視せず 「例外として追加」するだけに留めます。

初期 admin パスワード取得

kubectl -n argocd get secret argocd-initial-admin-secret \
  -o jsonpath=&quot;{.data.password}&quot; | base64 -d

kubectl -n argocd get secret argocd-initial-admin-secret \

-o jsonpath="{.data.password}" | base64 -d

出力された文字列は 初回ログイン専用 のパスワードです。必ず保存し、ログイン後に変更してください。

argocd CLI の取得（最新バイナリ）

# 最新タグを再利用してバイナリを取得
LATEST_TAG=$(curl -s https://api.github.com/repos/argoproj/argo-cd/releases/latest | jq -r .tag_name)
curl -sSL -o argocd &quot;https://github.com/argoproj/argo-cd/releases/download/${LATEST_TAG}/argocd-linux-amd64&quot;
chmod +x argocd
sudo mv argocd /usr/local/bin/

# 最新タグを再利用してバイナリを取得

LATEST_TAG=$(curl -s https://api.github.com/repos/argoproj/argo-cd/releases/latest | jq -r .tag_name)

curl -sSL -o argocd "https://github.com/argoproj/argo-cd/releases/download/${LATEST_TAG}/argocd-linux-amd64"

chmod +x argocd

sudo mv argocd /usr/local/bin/

Windows の場合は argocd-windows-amd64.exe を同様に取得し、PATH に追加してください。

CLI でのログインと --insecure の取扱い

# 例: 自己署名証明書を使用しているローカル環境のみ --insecure を付与
argocd login localhost:8080 \
  --username admin \
  --password &lt;取得したパスワード&gt; \
  --insecure

# 例: 自己署名証明書を使用しているローカル環境のみ --insecure を付与

argocd login localhost:8080 \

--username admin \

--password <取得したパスワード> \

--insecure

運用環境でのリスク
- 中間者攻撃（MITM）に対して暗号化が無効になる
- 認証情報が平文で送信される可能性

代替手段
1. Ingress/LoadBalancer に正規証明書を設定（Let's Encrypt など）
2. argocd-cm ConfigMap の tls.certificates 項目でサーバー証明書を直接注入
3. クライアント側に CA バンドルを配置し、--insecure を外す

本番環境では必ず 1 または 2 のいずれかを採用し、--insecure は使用しないよう徹底してください。

GitHub 連携とサンプルアプリのデプロイ

GitOps の核となるリポジトリ認証設定と、実際に Application を作成して自動同期させるまでを順番に解説します。ここでは SSH 鍵方式 を推奨しつつ、PAT（Personal Access Token）での代替手順も示します。

SSH キーによるリポジトリ認証（推奨）

# 1. SSH 鍵ペアを生成（パスフレーズは空でも可）
ssh-keygen -t ed25519 -C &quot;argocd@example.com&quot; -f ~/.ssh/argocd_key -N &quot;&quot;

# 2. 公開鍵を GitHub に登録
#    Settings → SSH and GPG keys → New SSH key

# 3. 秘密鍵を Kubernetes Secret として保存
kubectl -n argocd create secret generic github-ssh-key \
  --from-file=sshPrivateKey=~/.ssh/argocd_key

# 4. Argo CD が自動で検出し、リポジトリ設定に反映されます。

# 1. SSH 鍵ペアを生成（パスフレーズは空でも可）

ssh-keygen -t ed25519 -C "argocd@example.com" -f ~/.ssh/argocd_key -N ""

# 2. 公開鍵を GitHub に登録

# Settings → SSH and GPG keys → New SSH key

# 3. 秘密鍵を Kubernetes Secret として保存

kubectl -n argocd create secret generic github-ssh-key \

--from-file=sshPrivateKey=~/.ssh/argocd_key

# 4. Argo CD が自動で検出し、リポジトリ設定に反映されます。

HTTPS + PAT（代替手段）

手順	内容
1	GitHub の Settings → Developer settings → Personal access tokens で `repo` スコープ付きの PAT を作成
2	Secret 作成 `kubectl -n argocd create secret generic github-pat --from-literal=username=<GitHubユーザ> --from-literal=password=<PAT>`
3	UI/CLI の「Repository」追加画面で `type: https` とシークレット名を指定

Application マニフェスト（最小構成）

以下は公式サンプルリポジトリ argoproj/argo-cd-example-apps を対象にした Application 定義です。自動同期 (automated) が有効になっているため、Git にプッシュするだけで即時デプロイが走ります。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: guestbook
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/argoproj/argo-cd-example-apps.git
    targetRevision: HEAD
    path: guestbook
  destination:
    server: https://kubernetes.default.svc   # ローカル kind クラスタを指す
    namespace: default
  syncPolicy:
    automated:
      prune: true          # 不要リソースは自動削除
      selfHeal: true       # Git と乖離したら自動復旧
    retry:
      limit: 5

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

namespace: argocd

spec:

project: default

source:

repoURL: https://github.com/argoproj/argo-cd-example-apps.git

targetRevision: HEAD

path: guestbook

destination:

server: https://kubernetes.default.svc # ローカル kind クラスタを指す

namespace: default

syncPolicy:

automated:

prune: true # 不要リソースは自動削除

selfHeal: true # Git と乖離したら自動復旧

retry:

limit: 5

# マニフェスト適用で Argo CD に登録
kubectl apply -f guestbook-app.yaml -n argocd

# マニフェスト適用で Argo CD に登録

kubectl apply -f guestbook-app.yaml -n argocd

Sync 操作と結果確認

UI：Application 一覧 → 対象アプリ → SYNC ボタン → Synchronize
CLI：argocd app sync guestbook

デプロイ成功の目安は以下コマンドで Pod が READY 1/1 になることです。

kubectl get pods -n default -l app=guestbook

1 2	kubectl get pods -n default -l app=guestbook

本番環境への移行と高度なセキュリティ対策

ローカルでの検証が完了したら、本番クラスタへ同一マニフェストを適用します。実運用では 永続化、Ingress 設計、リソース制限、RBAC の細分化 が必須です。

本番向け設定チェックリスト

項目	推奨内容
外部 DB / 永続化	`argocd-dex`・`redis` などは StatefulSet と PVC を利用し、バックアップポリシーを策定
Ingress / LoadBalancer	NGINX Ingress Controller またはクラウド LB（ALB/ELB）で HTTPS 終端。`service.type=LoadBalancer` のみでは外部からの証明書管理が困難
リソース上限	`resources.requests.cpu: 200m`, `resources.limits.cpu: 500m`, `memory: 256Mi‑512Mi` をベースに調整
Namespace 分離	本番環境は `argocd-prod` 等別名で作成し、開発・ステージングと RBAC を分離

admin パスワードの安全な変更方法

以下コマンドはシェル展開を正しく行い、admin.passwordMtime に現在の UNIX 時間を設定します。--type=merge で既存シークレットに上書きする形です。

NEW_PASS=&quot;strongPassword!2026&quot;
kubectl -n argocd patch secret argocd-secret \
  --type=merge \
  -p &quot;{\&quot;stringData\&quot;:{\&quot;admin.password\&quot;:\&quot;${NEW_PASS}\&quot;,\&quot;admin.passwordMtime\&quot;:\&quot;$(date +%s)\&quot;}}&quot;

NEW_PASS="strongPassword!2026"

kubectl -n argocd patch secret argocd-secret \

--type=merge \

-p "{\"stringData\":{\"admin.password\":\"${NEW_PASS}\",\"admin.passwordMtime\":\"$(date +%s)\"}}"

ポイント：$(date +%s) がシェル側で評価され、JSON に正しい数値が埋め込まれます。以前の "$()" を文字列として渡すミスを防げます。

本番向け RBAC 設計（詳細ポリシー例）

argocd-rbac-cm ConfigMap にはロールベースのアクセス制御を書き込みます。実運用では以下のように プロジェクト単位、名前空間単位 の細かい権限付与が推奨されます。

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-rbac-cm
  namespace: argocd
data:
  policy.csv: |
    # 読み取り専用ロール（全リソース）
    p, role:readonly, applications, get, */*, allow

    # 開発者は自プロジェクトの Application の作成・更新・削除のみ可
    p, role:dev-team, applications, create, default/*, allow
    p, role:dev-team, applications, update, default/*, allow
    p, role:dev-team, applications, delete, default/*, allow

    # オペレーションチームは全プロジェクトの管理権限を保持
    p, role:ops, *, *, */*, allow

    # ユーザーとロールの紐付け（例：GitHub のメールアドレス）
    g, alice@example.com, role:dev-team
    g, bob@example.com,   role:readonly
    g, ops@example.com,   role:ops

apiVersion: v1

kind: ConfigMap

metadata:

namespace: argocd

data:

policy.csv: |

# 読み取り専用ロール（全リソース）

p, role:readonly, applications, get, */*, allow

# 開発者は自プロジェクトの Application の作成・更新・削除のみ可

p, role:dev-team, applications, create, default/*, allow

p, role:dev-team, applications, update, default/*, allow

p, role:dev-team, applications, delete, default/*, allow

# オペレーションチームは全プロジェクトの管理権限を保持

p, role:ops, *, *, */*, allow

# ユーザーとロールの紐付け（例：GitHub のメールアドレス）

g, alice@example.com, role:dev-team

g, bob@example.com, role:readonly

g, ops@example.com, role:ops

kubectl apply -f rbac-config.yaml -n argocd

1 2	kubectl apply -f rbac-config.yaml -n argocd

実務での留意点
- 最小権限の原則（Principle of Least Privilege） を徹底し、不要な * 許可は排除。
- OIDC / SAML 連携時は外部 IdP の属性マッピングでロール付与を自動化すると管理が楽になる。
- ポリシー変更後は必ず UI/CLI で権限テストを行い、意図しないアクセスが許可されていないか検証。

TLS 証明書の本番導入（Ingress 経由）

自己署名証明書から脱却し、公開 CA（例：Let’s Encrypt）で取得した証明書を Ingress に組み込みます。cert-manager がインストール済みの場合は以下だけで自動取得・更新が完了します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd-ingress
  namespace: argocd
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod   # cert-manager 用設定
spec:
  tls:
  - hosts:
    - argo.example.com
    secretName: argo-tls
  rules:
  - host: argo.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 443

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

namespace: argocd

annotations:

cert-manager.io/cluster-issuer: letsencrypt-prod # cert-manager 用設定

spec:

tls:

- hosts:

- argo.example.com

secretName: argo-tls

rules:

- host: argo.example.com

http:

paths:

- path: /

pathType: Prefix

backend:

service:

port:

number: 443

適用後、kubectl get secret -n argocd argo-tls -o yaml で証明書が格納されていることを確認してください。

まとめ

前提条件：最新版の kubectl・Docker・kind をインストールし、ローカル kind クラスタを作成すれば準備完了です。
最新マニフェスト取得：GitHub API で取得したタグ ($LATEST_TAG) を用いることで、バージョン固定のリスクを回避できます。
初期設定：Port‑Forward とシークレット取得で管理者パスワードを入手し、--insecure の使用はローカル限定に留め、実運用では正規証明書を必ず導入してください。
GitHub 連携：SSH 鍵方式が推奨です。PAT は代替として残しておくと便利です。
Application デプロイ：自動同期 (automated) により GitOps がシームレスに機能します。
本番移行：永続化、Ingress 設計、リソース制限、細分化された RBAC ポリシーを組み込むことで、運用レベルの安全性が確保できます。

この手順通りに実施すれば、初心者でも ローカル環境から本番クラスタまで 安全かつ最新状態の Argo CD を構築でき、GitOps による継続的デリバリー基盤を即座に活用できます。

スポンサードリンク

もっとスキルを活かしたいエンジニアへ

スポンサードリンク

働き方から選べる

無料で使えて良質な案件の情報収集ができるサービス

フルリモート・週3日・高単価、どんな条件も妥協したくないなら

フリーランスボードに無料会員登録する

利用者10万人以上。業界最大規模45万件の案件。AIマッチ機能や無料の相場情報が人気。

年収800万円以上のキャリアアップ・ハイクラス正社員を視野に入れているなら

Beyond Careerに無料相談する

内定獲得率90%以上。紹介先企業とは役員クラスのコネクションがある安心と信頼できるエージェント。

-ArgoCD

comment コメントをキャンセル

: ArgoCD

2026年ArgoCD GitOps導入のベストプラクティスと実践ガイド

2026年のGitOps導入においてArgoCDのAuto-Sync設定やリポジトリ分離戦略、多環境設計、セキュリティ対策などのベストプラクティスを解説。PRジェネレーターによる一時環境構築手法も紹介。

: ArgoCD

セルフマネージドArgoCDのカスタムヘルスチェック活用ガイド

セルフマネージド環境でのGitOps導入後、カスタムヘルスチェックが運用負荷の軽減に不可欠です。Red Hat公式ドキュメントに基づくresourceHealthChecksとCRDによるアプリケーション固有の健康状態判定手法を解説。

: ArgoCD

UbuntuでArgo CDをインストールする完全ガイド

Ubuntu環境にMicroK8s/Kindを用意し、公式マニフェストでArgo CDを導入する方法をステップバイステップで紹介します。

: ArgoCD

Argo CD と Jenkins を徹底比較！GitOps と CI/CD の選択ポイント

GitOps が注目される背景と CI/CD における役割を整理し、Argo CD の宣言的デプロイと Jenkins の手続き型パイプラインの違い、デプロイ速度・ロールバック・ドリフト防止機能、運用コストやスケーラビリティ、2025‑2026 年のベストプラクティスを比較します。

: ArgoCD

Argo CDポートフォワーディングの基本とトラブルシューティング

Kubernetes運用時に必要なArgo CDポートフォワーディング設定手順とKind環境でのポータル停止問題への対処法を解説しています。

AIエージェントと1Password連携のセキュリティ設計ガイド

コドモン導入成功事例とポイント | 業務効率化・児童観察の質向上

Argo CD のインストールと設定ガイド（kind・本番環境）

前提条件とインストール環境

必要ツールと推奨バージョン

ローカル kind クラスタ作成

Argo CD の公式マニフェストによるインストール

最新リリースタグの取得

Namespace 作成とマニフェスト適用

デプロイ結果の確認

UI と CLI の初期設定

Port‑Forward による UI アクセス

初期 admin パスワード取得

argocd CLI の取得（最新バイナリ）

CLI でのログインと --insecure の取扱い

GitHub 連携とサンプルアプリのデプロイ

SSH キーによるリポジトリ認証（推奨）

HTTPS + PAT（代替手段）

Application マニフェスト（最小構成）

Sync 操作と結果確認

本番環境への移行と高度なセキュリティ対策

本番向け設定チェックリスト

admin パスワードの安全な変更方法

本番向け RBAC 設計（詳細ポリシー例）

TLS 証明書の本番導入（Ingress 経由）

まとめ