2014/02/12 Docker Meetup in Tokyo #1 での発表内容です。 デモコード: https://github.com/ydnjp/docker-continuous-integration-workflow
![Dockerと継続的インテグレーション](https://cdn-ak-scissors.b.st-hatena.com/image/square/f8b0f89692aee0589045518d4a55d345642e2024/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2F140212docker-continuous-integration-140212022237-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
Google Container Engine(GKE)など、クラウドインフラ上でdockerコンテナを動作させる場合、データ確保のため外部ディスクを利用するケースが多々あります。 GKEでは、設定ファイルにpersistentDiskの設定を記述することで、dockerコンテナにpersistentDiskがmountされた状態で起動します。 この場合、外部ストレージのファイルパーミッションが問題となり、コンテナが起動できないトラブルによく遭遇します。 (AWSではためしていませんが、kubernetesではEBSも指定できるので、問題の構造は同様でしょう) 典型的な用途では、mysqlはmysqlユーザー、postgresqlはpostgresユーザーでDBディレクトリを読み書きできる必要があります。 そのため初回起動時にpersistentDiskのファイルオーナーを各ユーザーに変更
jenkins で回してる ci のジョブを digdag で書き直してみたけど、フローがひと目で分かるし、git で管理できるし、並列化も簡単だし最高だ。— Kosuke Adachi (@foostan) October 8, 2016 ということで Jenkins のジョブを Digdag に置き換えて Git で管理すると最高なので、今困っている人はやりましょう。1日あれば多分終わります。 今回試したのは CI のジョブですが、どんなジョブでも応用できると思います。 詳しく こないだ Rebuild 152 聴いていたらその会話の中に「Jenkinsおじさん」ってワードが出てきたんですよ。 rebuild.fm Jenkinsをそれなりの規模で使っている人ならお馴染みだと思うんですが、Jenkinsって自由度が高くてジョブの編集も簡単にできるから気をつけないとジョブがカオスな状態に
Jenkinsのデータを管理するフォルダ:/var/lib/jenkins/jenkins-data/ ビルド履歴を削除するジョブ名:test-job とします rm -rf /var/lib/jenkins/jenkins-data/jobs/test-job/builds echo 1 > /var/lib/jenkins/jenkins-data/jobs/test-job/nextBuildNumber buildsフォルダを削除し、ジョブを管理するフォルダ配下のnextBuildNumberファイルの値を1に修正します その後Jenkinsを再起動します すると、ビルド履歴が全削除されビルドの実行番号も1番からとなります ポイントはフォルダの削除とファイルの修正を実施したあとにちゃんと再起動をするところ Jenkinsはどうやら一旦ファイルの情報をJVM上にキャッシュしているよう
はじめに 「ほぼ」同じ構成のサーバがN台あって,それぞれに対して同じスクリプトを実行したい。このときスクリプトはひとつに集約したい(=各サーバにスクリプト配置したくない)。こういうときって、どうするのが定番なんだろう・・・— Kensho (@ni66ling) February 14, 2015 ローカルのスクリプトをリモートで実行したいけどどうやれば?という話. どうやるのが定番なのか?は結局わかっていないが,一応できるにはできたのでメモ. やりかた sshコマンドにパイプでローカルのスクリプトを引き渡す.*1 $ cat [local_script.sh] | ssh [user]@[host] bash 補足: ローカルにおける変数をリモートスクリプト内で使うには プロセス置換*2を用いる. $ param="local" $ cat <(echo -e "param=\"${pa
jenkins(実行ユーザ:jenkins)のcronでsudoを使う必要があり、/etc/sudoersの設定を変えたのでメモ。 ユーザ:jenkinsをtty(コンソール)無しでsudoさせるため、こんな感じで設定しました。 sudo /usr/sbin/visudo #Defaults requiretty # tty無しの場合sudoさせない(コメントアウト) Defaults:jenkins !requiretty # ユーザjenkinsはtty無しでsudo可能 jenkins ALL=(ALL) NOPASSWD:ALL # ユーザjenkinsはパスワード無しでsudo可能 ちょっと解説 sshコマンドやcronの中でsudoを使うスクリプトを使う場合によくあるケースなんですが sudo: sorry, you must have a tty to run sudo こん
Gitでバージョン管理をしていると、本番サーバにデプロイする際に、クライアントでpush、そして本番サーバにログインしてgit pull、ってやるのは面倒臭いですよね。そんな不毛な操作は自動化するのがプログラマとしては当然です。 GitHub上のリポジトリで、デプロイの自動化をやるにはWebhookやTravis CI、JenkinsなどのCIツールとの連携を考えます。選択肢は多々あり、それぞれにメリット、デメリットはありますが、今回は後々、FuelPHPのユニットテスト自動化までを見据えて、Jenkinsによるデプロイ自動化を試してみようと思います。 サーバ構成イメージ 今回、Jenkinsを導入するにあたって、専用のEC2インスタンスを立ち上げます。このインスタンスをCIサーバとして利用していきます。 GitHubリポジトリへプッシュされたとき、GitHubはJenkinsサーバへ通知
1.544 APサーバ Tomcat 7.0.42 インストール war ファイルのダウンロード Welcome to Jenkins CI! | Jenkins CI にアクセスして、 war ファイルをダウンロードする。 JENKINS_HOME の設定 環境変数 JENKINS_HOME を設定する。 この JENKINS_HOME には、バージョン管理システムからチェックアウトしてきたファイルなどが保存される。 デフォルトでは、実行ユーザのホームフォルダ以下に .jenkins というフォルダが作成され、そこが利用される。 デプロイ Tomcat の webapps フォルダにダウンロードした war ファイルを配置する。 動作確認 Tomcat を起動して http://localhost:8080/jenkins/ にアクセスする(ホストとポートは適宜読み替え)。 簡単なプロジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く