「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

【GitLab 公式 を訳してみた】GitLab CI~Dplをデプロイ・ツールとして使う

 GitLab Documentation>GitLab Continuous Integration (GitLab CI)>GitLab CI 設定サンプル集
>Dplをデプロイ・ツールとして使う

  Travis CIにて開発され、そこで使われてきたDpl(dee-pee-ell)ですが、GitLab CIで使うこともできます。

 注:Dplを使う前に、現在ご利用のプロバイダがツールに対応しているかどうかを確認しておいてください。(こちらのページを参考に→github.com/travis-ci/dpl#supported-providers

 

  必要条件

  Dplの使用にはgemを使います。ruby 1.9.3以上が必要です。
 

  基本設定

  Dplをインストールするには、大抵のマシンで

======================
gem install dpl
======================

  というコマンドを使います。全てのコマンドを確認するときには、CIサーバーより、ローカル環境からコマンドを出した方がよいでしょう。

  Debian系Linuxの場合、次のコマンドでRubyをインストールします。

======================
apt-get update
apt-get install ruby-dev
======================

  Dplに対応しているプロバイダは、Heroku、Cloud Foundry、AWS/S3など数多く、使用に特別な設定が要らないサービスもありますが、中には追加パラメータが必要なものがあります。

  たとえば、アプリケーションをHerokuにデプロイする場合、「gitlab.ci.yml」というファイルにプロバイダ「heroku」と、そして「app」のうしろにAPIキーを明記する必要があります。
 使用可能なパラメータはこちらのページでご確認ください。(github.com/travis-ci/dpl#heroku

============================================
staging:
  stage: deploy
  script:
  - gem install dpl
  - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
============================================

  上の例では、「my-app-staging」をHerokuサーバーにデプロイする時にDplを使っています。Herokuサーバーについてはその後の「HEROKU_STAGING_API_KEY」という変数で表しています。

  とはいえ、これはほんの1例に過ぎません。他のプロバイダについては「サポートしているプロバイダ一覧」から対応の仕方を確認してください。少々長いリストですが、よろしくお願いします。

 

  DplをDockerで使う

  GitLab ランナーを使う時には、サーバーのシェルコマンドを使って設定していくのが一般的ですが、それはローカル環境でランナーを支度でき、もちろん設定もローカルで可能であることが前提であります。(例: gitlab_runnerあるいは gitlab_ci_multi_runner

 しかし、全ての人がわざわざランナー用のサーバーを用意できるとも限りません。
 そのようなときに使われるのが、Dockerコンテナです。もちろん、DockerコンテナでDplを使うことは可能です。
 ただ1つ注意点がありまして、Dockerコンテナには最初からRubyのランタイムがインストールされているわけではありません。
 
 よって、「.gitlab-ci.yml」ファイルの設定は、Rubyのインストールから始まります。

============================================
staging:
  stage: deploy
  script:
  - apt-get update -yq
  - apt-get install -y ruby-dev
  - gem install dpl
  - dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
  only:
  - master
============================================

  まず最初に「apt-get update -yq」でパッケージリストを更新して、その次に「apt-get install -y ruby-dev」でRubyランタイムをインストールします。
 あとは、先ほど紹介した短いコンフィグと同じ内容です。

 この例は、DockerでDebian系システムを動かしていることを想定しています。


 

  「staging」と「production」でどのような違いを持たせるか

  アプリを「deploy」するといっても、そのアプリが試作品か発表用かで、環境を分けられた方が便利です。

  GitLab CIでは、「master」ブランチへのデプロイを「staging」job、「tag」が付いた試作アプリケーションのデプロイを「production」jobの2ルートに分類することができます。

 (訳者より一言:ちなみに、この「master」と「tag」の解釈を逆転させた考え方もあるようです。この場合「tag」が正式発表用になっています。)

 そこで以下のような設定が成立します。
 最後にこれを設定しておくと、Dplをさらに使いこなせるようになるはずです。

============================================
staging:
  stage: deploy
  script:
  - gem install dpl
 
- dpl --provider=heroku --app=my-app-staging --api-key=$HEROKU_STAGING_API_KEY
  only:
  - master

production:
  stage
: deploy
  script:
  - gem install dpl
 
- dpl --provider=heroku --app=my-app-production --api-key=$HEROKU_PRODUCTION_API_KEY
  only:
  - tags
============================================

  同じdeployの工程でも、状況に応じて異なる2つのルートを作成できました。

  1. staging - masterブランチにプッシュがあったときに、変数に応じたdeployを開始するように設定
  2. production - tagにプッシュがあったときに、変数に応じたdeployを開始するように設定

  そして、jobごとに2つの変数を設けました。

  1. HEROKU_STAGING_API_KEY - 「staging」に送られたアプリをどのように展開するか
  2. HEROKU_PRODUCTION_API_KEY - 「produciton」に送られたアプリをどのように展開するか



    APIキーの設定

  外部変数に許可を出すには、「Settings→Pipelines→Secret variables」に移動して適切な設定をしてください。

 変数はプロジェクトの設定を決定づけるうえで重要な役割を果たします。なかでも、「Secret variables」はレポジトリにない変数をどうしても設定しなくてはならない時に使われます。
 ここで登録されなかった変数においては、「.gitlab-ci.yml」に記述しても実行されることがありません。
 また、「Secret variables(秘密変数)」に登録された変数は、jobのログに記録されません。
 

  それから、「.gitlab-ci.yml」に記載されている変数の前には「$」という記号がありますが、Windows Batchランナーの場合、変数を「%」で囲まなくてはなりません。

  1. $SECRET_VARIABLE - Windowsランナーを除くシステム
  2. %SECRET_VARIABLE% - Windows Batchランナーを使っている場合

  詳しくは「CIで使える変数」をご覧ください。

 Edit this page

 
PDF
更新日:2017-11-17 23:49:38 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://docs.gitlab.com/ee/ci/examples/deployment/README.html 原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL:https://gitlab.com/gitlab-com/gitlab-docs/blob/master/LICENSE) この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

僕がHugo静的サイト・ジェネレータをGitLabで使うときにしたCI設定 | from Leow Kah Man - Tech Blog

 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとCIビルドが自動的にできるところが便利です。  僕はGitLabのレポジトリにNodeJS Dockerイメージを構…2017-11-18 13:00:02

【GitLab 公式 を訳してみた】Dockerイメージを使う

GitLab Documentation > GitLab Continuous Integration (GitLab CI) > Docker integration >Dockerイメージを使う  GitLab CIは、GitLab ランナーと連携して、Dockerエンジンを様…2017-11-18 00:10:16

【GitLab 公式 を訳してみた】 .gitlab-ci.yml 設定メニュー

 (訳者より:翻訳がもうだいぶ進んだところで、GitLab CIについてネットで検索をかけてみたところ、 Qiitaにてynott様が公開されたバージョン があることに気がつきました。  原…2017-11-17 23:50:27

【GitLab 公式 を訳してみた】GitLab CI/CDで使える変数

GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI/CDで使えるAPI変数  GitLab ランナーは、CIから送られてきたjobをもとに、ビルド環境を整えます。…2017-11-17 23:50:02