CDK for TerraformでGitHub Providerを使ってGitHubリポジトリを作成してみる

CDK for TerraformでGitHub Providerを使ってGitHubリポジトリを作成してみる

Clock Icon2023.03.07

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

「CDKでGithubリポジトリの設定をしてみたいな」

みなさん、TerraformのGitHub Provider使っていますか。

GitHubのリポジトリの作成やユーザー管理をTerraformで行うことができて便利です。

今回はCDKTFを使って、GitHubリポジトリを作成します。

サンプルコードは以下にあります。

msato0731/cdktf-github-repo-sample

やってみた

ブログ用のサンプルコードを置くリポジトリをCDKTFで作ってみます。

具体的には、CDKTFを使って以下の作業を行います。

  • GitHub Repositoryを作成
  • リポジトリの公開範囲はPublic
  • Pull Requestマージ後にブランチ自動削除を有効
  • Issueを有効化
  • Terraform用の.gitignoreを用意する
  • README.mdを作成する

事前準備: GitHub個人用アクセストークンの準備

まずは、CDKTFでGitHubを操作するために、Tokenを作成します。

以下を参考に個人用アクセストークンを作成します。

個人用アクセス トークンの作成 - GitHub Docs

作成する個人用アクセストークンには以下の権限を与えます。

  • Repository Access: All repositories
  • Permission:
    • Repository permissions
    • Administration: Read and write
    • Contents: Read and write

トークンは環境変数として、CDKTFを実行するターミナルに設定しておきます。

$ export GITHUB_TOKEN=github_pat_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
$ echo $GITHUB_TOKEN
github_pat_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

CDKTFの用意

cdktf initでCDKTFのディレクトリを作成します。 今回は検証のため、--localフラグをつけて、stateをlocalに置いています。

$ cdktf init --template=typescript --local

Githubリポジトリを作成・設定している部分は以下になります。

import { Construct } from "constructs";
import { App, TerraformStack, TerraformOutput, Fn } from "cdktf";
import { repository, provider, repositoryFile } from '@cdktf/provider-github'
import { join } from "path";

class GithubRepoStack extends TerraformStack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    new provider.GithubProvider(this, 'github', {
      token: process.env.GITHUB_TOKEN,
      owner: 'msato0731' #自分のアカウント名または、Organization名に変更する
    });

    const repo = new repository.Repository(this, 'TestRepo', {
      name: 'cdktf-github-sample',
      visibility: 'public',
      deleteBranchOnMerge: true,
      hasIssues: true,
      gitignoreTemplate: 'Terraform',
      autoInit: true
    });

    new repositoryFile.RepositoryFile(this, 'File', {
      file: 'README.md',
      repository: repo.name,
      content: Fn.templatefile(join(__dirname, "./templates/README.md.tftpl"), { repo_name: repo.name}),
      overwriteOnCreate: true
    })

    new TerraformOutput(this, "RepoHttpUrl", {
      value: repo.httpCloneUrl
    });
    new TerraformOutput(this, "RepoSshUrl", {
      value: repo.sshCloneUrl
    });
  }
}

const app = new App();
new GithubRepoStack(app, "github-repo-sample");
app.synth();

GitHub Providerの宣言の部分で、Organizationを指定することもできます。 (今回は自分のアカウントを指定しました)

const repo = new ~~の部分で具体的にGitHubリポジトリを設定しています。

.gitignoreは自分で作成して、ファイルを指定する形(コード中のREADME.mdのように)にしてもいいです。 今回は、GitHubで事前に用意されているTerraformの.gitignoreを指定しました。

github/gitignore: A collection of useful .gitignore templates

Github Providerはリポジトリを作成するだけではなく、ファイルをcommitすることもできます。

README.mdをローカルに用意しておいて、リポジトリ作成時にコミットに含めるようにしました。

Terraformのtemplatefile関数を使って、リポジトリ名を渡しています。 (ブログタイトルとURLはリポジトリ作成時には、決まっていないことが多いので後で変更するようにしています)

# ${repo_name}

[ブログタイトル](URL)

最後に、リポジトリのSSHとHTTPのURLをアウトプットしています。 SSHはgitのCLIから繋ぐ用で、HTTPは作った後にリポジトリの状態を確認するようです。

他の設定値は以下のドキュメントから確認できます。

cdktf-provider-github/API.typescript.md at main · cdktf/cdktf-provider-github

CDKTF実行・作成されたリソースの確認

コマンドを実行して、実際にリポジトリを作ってみましょう。

$ cdktf list
github-repo-sample
$ cdktf deploy github-repo-sample
~~省略~~
Outputs:

RepoHttpUrl = "https://github.com/msato0731/cdktf-github-sample.git"
RepoSshUrl = "[email protected]:msato0731/cdktf-github-sample.git"

リポジトリがPublicで、README.md.gitignoreがある状態でリポジトリを作成できました。Issuesも有効化されていますね。

Pull Requestマージ後の自動HEADブランチ削除も有効にできています。

確認が終わったら以下のコマンドで削除できます。

$ cdktf destroy github-repo-sample

おわりに

CDKTFでGitHubリポジトリを作成する方法でした。

今回はシンプルな設定だけでしたが、チーム開発で必要なコラボレータの追加や保護ブランチの設定なども可能です。今後試していきたいと思います。

クラウドリソース(AWS、Google Cloud、Azure)以外のProviderの場合、state置き場が悩ましいと感じた方もいるかもしれません。

GitHub以外変更しないのに、S3などへのアクセス権限が必要なのもアレですし、どこのAWSアカウントに置くべきか少し迷います。

そういった場合は、Terraform Cloudを使うのがおすすめです。

Terraform Cloudの機能の1つにstate管理があります。(Freeプランでも使えます)

stateロック機能もデフォルトで付いていますし、state管理用のS3やDynamoDBなどを各アカウントに作る必要がありません。

Terraform Cloudに一元化してしまえば、Provider毎にどこにstateを管理するべきか迷うことが無くなります。

以上、AWS事業本部の佐藤(@chari7311)でした。

あわせて読みたい記事

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.