Skip to main content
ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。
GitHub AEは、現在限定リリース中です。詳細については営業チームにお問い合わせください。

デプロイキーの管理

デプロイメントのスクリプトを自動化する際にサーバー上のSSHキーを管理する様々な方法と、どれが最適な方法かを学んでください。

SSHエージェントのフォワーディング、OAuthトークンでのHTTPS、デプロイキー、マシンユーザを使ってデプロイメントスクリプトを自動化する際に、サーバー上のSSHキーを管理できます。

SSHエージェントのフォワーディング

多くの場合、特にプロジェクトの開始時には、SSHエージェントのフォワーディングが最も素早くシンプルに使える方法です。 エージェントのフォワーディングでは、ローカルの開発コンピュータで使うのと同じSSHキーを使います。

長所

  • 新しいキーを生成したり追跡したりしなくていい。
  • キーの管理は不要。ユーザはローカルと同じ権限をサーバーでも持つ。
  • サーバーにキーは保存されないので、サーバーが侵害を受けた場合でも、侵害されたキーを追跡して削除する必要はない。

短所

  • ユーザはデプロイするためにSSHしなければならない。自動化されたデプロイプロセスは利用できない。
  • SSHエージェントのフォワーディングは、Windowsのユーザが実行するのが面倒。

セットアップ

  1. エージェントのフォワーディングをローカルでオンにしてください。 詳しい情報についてはSSHエージェントフォワーディングのガイドを参照してください。
  2. エージェントフォワーディングを使用するように、デプロイスクリプトを設定してください。 For example, on a bash script, enabling agent forwarding would look something like this: ssh -A serverA 'bash -s' < deploy.sh

OAuthトークンを使ったHTTPSでのクローニング

If you don't want to use SSH keys, you can use HTTPS with OAuth tokens.

長所

  • サーバーにアクセスできる人なら、リポジトリをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • 複数のトークン(ユーザごと)が必要ない。サーバーごとに1つのトークンで十分。
  • トークンはいつでも取り消しできるので、本質的には使い捨てのパスワードにすることができる。

短所

  • トークンを確実に正しいアクセススコープで設定しなければならない。
  • トークンは本質的にはパスワードであり、パスワードと同じように保護しなければならない。

セットアップ

See our guide on creating a personal access token.

デプロイキー

You can launch projects from a repository on GitHub AE to your server by using a deploy key, which is an SSH key that grants access to a single repository. GitHub AE attaches the public part of the key directly to your repository instead of a personal account, and the private part of the key remains on your server. 詳しい情報については「デプロイメントのデリバリー」を参照してください。

書き込みアクセス権を持つキーをデプロイすれば、管理アクセス権を持つOrganizationのメンバー、あるいは個人リポジトリのコラボレータと同じアクションを行えます。 For more information, see "Repository roles for an organization" and "Permission levels for a personal account repository."

長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • デプロイキーはデフォルトではリードオンリーだが、リポジトリに追加する際には書き込みアクセス権を与えることができる。

短所

  • デプロイキーは単一のリポジトリに対するアクセスだけを許可できる。 より複雑なプロジェクトは、同じサーバーからプルする多くのリポジトリを持っていることがある。
  • デプロイキーは通常パスフレーズで保護されていないので、サーバーが侵害されると簡単にキーにアクセスされることになる。

セットアップ

  1. Run the ssh-keygen procedure on your server, and remember where you save the generated public and private rsa key pair key pair.
  2. GitHub AEの任意のページの右上で、プロフィールの写真をクリックし、続いてYour profile(あなたのプロフィール)をクリックしてください。 プロフィールへのアクセス
  3. プロフィールページでRepositories(リポジトリ)をクリックし、続いてリポジトリの名前をクリックしてください。 リポジトリのリンク
  4. リポジトリでSettings(設定)をクリックしてください。 リポジトリの設定
  5. サイドバーでDeploy Keys(デプロイキー)をクリックし、続いてAdd deploy key(デプロイキーの追加)をクリックしてください。 デプロイキーのリンクの追加
  6. タイトルを入力し、公開鍵に貼り付けてください。 デプロイキーのページ
  7. このキーにリポジトリへの書き込みアクセスを許可したい場合は、Allow write access(書き込みアクセスの許可)を選択してください。 書き込みアクセス権を持つデプロイキーを使うと、リポジトリにデプロイメントのプッシュができるようになります。
  8. Add key(キーの追加)をクリックしてください。

1つのサーバー上で複数のリポジトリを利用する

1つのサーバー上で複数のリポジトリを使うなら、それぞれのリポジトリに対して専用のキーペアを生成しなければなりません。 複数のリポジトリでデプロイキーを再利用することはできません。

サーバーのSSH設定ファイル(通常は~/.ssh/config)に、それぞれのリポジトリに対してエイリアスエントリを追加してください。 例:

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
  • Host my-GHE-hostname.com-repo-0 - リポジトリのエイリアス。
  • Hostname my-GHE-hostname.com - エイリアスで使用するホスト名を設定する。
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key - このエイリアスに秘密鍵を割り当てる。

こうすれば、ホスト名のエイリアスを使ってSSHでリポジトリとやりとりできます。この場合、このエイリアスに割り当てられたユニークなデプロイキーが使われます。 例:

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

サーバー間トークン

サーバーがOrganizationをまたいでリポジトリにアクセスする必要がある場合、GitHub Appで必要なアクセスを定義して、そのGitHub Appからスコープを厳格に設定したサーバー対サーバーのトークンを生成します。 サーバー対サーバーのトークンは単一または複数のリポジトリをスコープとすることができ、権限を細かく設定できます。 たとえば、リポジトリのコンテンツへの読み取り専用アクセス権を持つトークンを生成できます。

GitHub AppはGitHub AEでも主役級の存在なので、サーバー間トークンはあらゆるGitHubユーザから分離され、「サービストークン」に相当します。 さらに、サーバー間トークンには独自のレート制限があり、その制限は実行されるOrganizationの規模に応じて拡大されます。 For more information, see Rate limits for GitHub Apps.

長所

  • 権限設定と有効期限 (1時間、またはAPIで手動で取り消された場合にはそれ以下) が明確に定義された、スコープが厳格なトークン。
  • Organizationの規模に従って拡大する、独自のレート制限。
  • GitHubユーザIDと分離されているため、ライセンスのシート数を消費しない。
  • パスワードが付与されないので、直接サインインされない。

短所

  • GitHub Appを作成するには追加設定が必要。
  • サーバー間トークンは1時間後に期限切れとなるので、再生成する必要がある (通常はコードを使用して、オンデマンドで行なう)。

セットアップ

  1. GitHub Appをパブリックにするかプライベートにするか決定します。 GitHub AppがOrganization内のリポジトリのみで動作する場合は、プライベートに設定した方がいいでしょう。
  2. リポジトリのコンテンツへの読み取り専用アクセスなど、GitHub Appが必要とする権限を決定します。
  3. Organizationの設定ページからGitHub Appを作成します。 詳しい情報については、「GitHub Appを作成する」を参照してください。
  4. GitHub App idをメモします。
  5. GitHub Appの秘密鍵を生成してダウンロードし、安全な方法で保存します。 詳しい情報については、秘密鍵を生成するを参照してください。
  6. 動作させたいリポジトリにGitHubをインストールします。Organizationの全リポジトリにGitHub Appをインストールしても構いません。
  7. GitHub AppとOrganizationリポジトリとの接続を表わすinstallation_idを特定します。 GitHub AppとOrganizationの各ペアには、最大1つのinstallation_idがあります。 認証されたアプリケーションのOrganizationインストール情報を取得することで、installation_idを識別できます。 このためには、JWTを使用して、GitHub Appとして認証する必要があります。詳細については、「GitHub Appとして認証する」を参照してください。
  8. 対応するREST APIエンドポイントを使用して、サーバー間トークンを生成します。「アプリケーションに対するインストールアクセストークンの作成」を参照してください。 このためには、JWTを使用してGitHub Appとして認証する必要があります。詳しい情報については、「GitHub App として認証する」および「インストールとして認証を行う」を参照してください。
  9. このサーバー間トークンを使用して、REST、GraphQL API、またはGitクライアント経由でリポジトリとやり取りします。

マシンユーザ

サーバーが複数のリポジトリにアクセスする必要がある場合、新しいアカウントをGitHub AEで作成し、自動化専用に使われるSSHキーを添付できます。 GitHub AEのこのアカウントは人間によって使用されるものではないため、マシンユーザと呼ばれます。 マシンユーザは、個人リポジトリにはコラボレータとして(読み書きのアクセスを許可)、Organizationのリポジトリには外部のコラボレータとして(読み書き及び管理アクセスを許可)、あるいは自動化する必要があるリポジトリへのアクセスを持つTeamに(そのTeamの権限を許可)追加できます。

長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • (人間の)ユーザがローカルのSSH設定を変更する必要がない。
  • 複数のキーは必要ない。サーバーごとに1つでよい。

短所

  • Organizationだけがマシンユーザをリードオンリーのアクセスにできる。 個人リポジトリは、常にコラボレータの読み書きアクセスを許可する。
  • マシンユーザのキーは、デプロイキーのように、通常パスフレーズで保護されない。

セットアップ

  1. サーバー上でssh-keygenの手順を実行し、公開鍵をマシンユーザアカウントに添付してください。
  2. マシンユーザアカウントに自動化したいリポジトリへのアクセスを付与してください。 これは、アカウントをコラボレータ外部のコラボレータとして、あるいはOrganization内のTeamに追加することでも行えます。

参考リンク