静的HTML公開フローをサーバレスでDevOps！(Github,CircleCI,AWS S3) 前編 - Qiita
コーポレートサイトなどの静的サイトを、Github+CircleCi+S3webhostingでサーバレスDevOpsを実現。 主な利点 ・Github操作のみでデプロイを自動化。 ・サーバレスなのでサーバ運用不要。 ・**ステージングサイトには閲覧制限(許可IP制）**を設けることで、外部会社との連携も安全。 #構築内容 AWS S3 webhosting構築 Githubリポジトリ作成 静的ページを用意 HTML+CSS(bootstrap) CircleCIでのオートデプロイ オートデプロイテスト +αでフォームサイトはlambda,cognitoで実装 6は後編で掲載予定。 #想定フロー 各自ローカル環境でHTML編集。Githubで管理。 stagingブランチへのgit pushでステージングサイトへ自動デプロイ (ステージングサイトは自社サイトのみ閲覧可能） pullreqし
CircleCIでDocker v1.9.0を使う方法 - Qiita
追記 さらに新しいバージョンきてた。 Docker 1.10.0 is available (Beta) - Build Environment - CircleCI Community Discussion きっかけ @minodisk 突然失礼します。今日公開された docker-1.9 を使う前提ですが、いまのことろ、https://t.co/ALENbOAoat こういう方法になると思います。 — mapk0y (@mapk0y) 2015, 11月 4 Docker1.9では、ビルド時にDockerfileから参照可能な引数を渡せるようになったと。 @mapk0y さんに示して頂いたIssueがまさにやりたいことだった。あと1.9リリース当日でタイムリーすぎ。 Dockerビルド時に引数を指定する
CircleCI で Docker Container を Serverspec でテストする
Serverspec の Docker Backend を使った Docker コンテナのテストを CircleCI 上で実行する際、多少手こずったので、その試行錯誤によってできた、サンプルプロジェクトを公開しました。 GitHub Repository quay.io Registry CircleCI Builds 前回の記事で紹介した事例は Rails を採用していたので、コンテナ側にも Ruby がインストールされており、コンテナ側にマウントするだけで Serverspec を実行できました。 docker run \ -e DATABASE_URL="${DATABASE_URL}" \ -e REDIS_URL="${REDIS_URL}" \ -v "$(pwd)/docker/serverspec"\:/mnt/serverspec \ --name "serverspec
GitHub + CircleCI + Capistrano + Slack + Hubot で快適リリース生活 | QUARTETCOM TECH BLOG
こんにちは、@ttskchです。先日、Symfony Meetup #5のLTでChatOpsについて発表させていただきました。 発表に使用したスライドはこちらにあります。 具体的には、PHP（特にSymfony2）プロジェクトの開発・リリースのプロセスについてのお話しです。 ここでは、その発表の内容をもう少し詳しく解説したいと思います。大きく5つのステップに分けて、一つずつ解説していきます。少し長いですがお付き合いください。 Step 1. CIの導入 Step 2. Capistranoの導入 Step 3. デプロイの自動化 Step 4. リリースPR作成のQA最適化 Step 5. リリースPR作成のChatOps化 Step 1. CIの導入 まず一番初めにやるべきはCIの導入です。弊社ではCIサービスにCircleCIを使っています。 CircleCIとGitHubを連携させ
Jenkinsと完全にサヨナラして、CircleCIに移行した話 - tehepero note(・ω<)
2015-07-02 Jenkinsと完全にサヨナラして、CircleCIに移行した話 CI Jenkins CircleCI 長らくCIはJenkinsを利用して開発をしてきて、Hudson時代からご愛顧してきたのですが、この春から新しくスタートしたプロジェクトではJenkinsを利用しないという決断をしました。 Jenkinsとサヨナラした理由 複数プロジェクトで共有して利用するのがツライ うちの会社では共通で用意されたJenkinsがあって（それなりにスペック高くて、slaveもぶら下がってる）、色々なプロジェクトがそれを利用しています。 このケースの問題点は何よりもランタイムやSDKを共有してしまうことにあります。全てのビルドに副作用を与えることなく、ランタイムやSDKを追加・更新するのが簡単ではありません。それを滞りなくやるには事前にどのビルドが何を使っているかを把握したり、利用
CircleCIアンチパターン 2015春 - tehepero note(・ω<)
2015-03-31 CircleCIアンチパターン 2015春 CI CircleCI Docker 今日はCircleCIで気持ちよくCIを回すために、抑えておいた方が良いアンチパターンについて書きます。わりと基本的な話なので、心当たりがあれば見直してみると良いと思います。 Fat Repository Anti Pattern（巨大なリポジトリ） CircleCIのコンテナは使い捨てですが、対象のリポジトリを毎回cloneするのではなくて、2回目移行は前回のCI時にキャッシュしておいたリポジトリを利用することで差分取得を実現しています。 checkoutフェーズのRestore source cacheのことですね。 この手法によって最新取得のコストを大幅に低減することができますが、コンテナ初期化時にS3からリポジトリのアーカイブを取得するという特性上、あまりにも巨大な数GB超えのリ
CIツール@福岡を主催した話 - nobkzのブログ
CIツール@福岡を主催した話 今回のエントリについて。 僕は福岡では結構いろいろな勉強会を、主催で開催してきて、実は、結構自分で、自分が主催した勉強会について、記録や評価を残したりしているが、なんか、自分の中に漬けておくのがもったいないと思うようになってきた。 なんで、公開できる範囲で、できるだけオープンにしようと思った。そして、その情報が、他の勉強会の主催、これから主催する方の参考になるようになればと思って、この記事を書こうと考えている。 とまぁ、ぐだぐだ前口上を述べたが、つまり、なにがしたいかって言えば、このブログはあるいみ、主催の失敗記録だ。失敗は反省するべきだけでは無く、今後何をしていくべきか?ということが大事であって、できるだけそういうことができればなと考えている。 ** 追記 追記1 失敗記録とは言ったが、細かいところの失敗をできるだけ書いて行こうって話でつ。まぁ、あんまり失敗
CircleCI + DockerでサーバCI始めました | feedforce Engineers' blog
はじめまして！今年１月からジョインしましたtjinjinです。feedforceではアニメインフラを担当しています。ちなみに今季オススメアニメはSHIROBAKOです。 今回サーバCIにDockerを導入しましたので、実際の設定や工夫した点など投稿したいと思います。 feedforceのサーバCI 弊社ではこれまでCircleCIまたはJenkinsとAWSを組み合わせてサーバのCIを行って参りました。 参考: JenkinsでサーバのCIを始めました しかし、CircleCIを利用するプロジェクトが増えるにつれ、CircleCIに実行待ちが発生するようになりました。CircleCIの実行ログを確認したところ、AWSのセットアップに時間がかかっていることがわかったので、環境のセットアップ時間を短縮できるもののはないかと探していました。そんな折、Dockerがいいのではという話を耳にしました
Terraform + GitHub + CircleCI + Atlasを利用してAWSの操作を自動化した - Glide Note
TL;DR Terraform + GitHub + CircleCI + Atlas を用いてAWSの操作を自動化した 各ツールの役割は下記のような感じ Terraform => インフラへの変更ツール GitHub => .tfファイルのバージョン管理 CircleCI => CI、Terraformをawsに対して実行 Atlas => インフラの状態を記録するterraform.tfstateの管理 インフラの継続的デリバリー - naoyaのはてなダイアリーにて、言及されていた範囲(Route53の変更、Chefの適用)をAWSの操作全体に拡大した 背景 今までの問題点 AWSの各種操作がブラウザからポチポチ業… 手作業なので誤操作に気づきにくい。事故りやすい インフラの実構成がバージョン管理出来ていない ちなみにRoute53に関してはroadworkerを用いてコードで管理済
CircleCIでDockerコンテナ上でテストするときに環境変数を渡す - Qiita
CircleCIでDockerのイメージをつくって、つくったイメージをつかってテストを実行している。 しかし、CIで使えるサービス類の一部が使えなかったりすることがおきていてつらい。 環境変数をコンテナに引き継ぎして、渡してやればなんとかなるものもいくつかある。 しかし、テストを実行するコマンドが長くなって、保守はしにくいしつらい。 そこでスクリプトをかいた。 #!/bin/sh IMAGE="eiel/hoge" CMD="bin/rake" OPTIONS="-it --link my-db:db" ENVS="CODECLIMATE_REPO_TOKEN" DEFAULT_ENVS="CIRCLE_ARTIFACTS CIRCLE_BRANCH CIRCLE_BUILD_NUM CIRCLE_COMPARE_URL CIRCLE_NODE_INDEX CIRCLE_NODE_TOTA
細かすぎて伝わらないかもしれない、CircleCIでDockerをごにょごにょするときのスピードアップテク - パラボラアンテナと星の日記
前回、「Dockerコンテナにcookしserverspecでテストをする」ということをやりました。 キャッシュ活用などによる高速化などが課題でした。今回はいくつかの課題を解決させ、テスト時間の短縮を図りました。 (「スピードアップテク」とか書きましたが、勝手に自分がハマってたところを改善したりしてるだけの箇所もあります。) 先に結論：対策後のビルド時間 対策前(build#9) docker imageキャッシュ有効時(build#55) docker imageキャッシュ無効時(build#54) load docker image 1m41s 0m20s 1m00s knife solo cook(nginxのインストール) 2m56s 0m12s 0m21s (other) (1m03s) (0m41s) (1m06s) TOTAL 5m40s 1m13s(!!!!!) 2m27s
Docker on CircleCIでchefのcookbookをserverspecでテスト - パラボラアンテナと星の日記
CircleCI自体もコンテナなんだが、さらにその上でdockerコンテナ立ててcookbookのテストしてしまうというアレです。 「Docker使えるならChef要らないじゃん」という話は大賛成なんだが、既存のcookbook資産を使いたいことも、まあある。 【追記】続きにさらにテストの時間短縮させる工夫書いた 動いたの？ 動いた!!!!!!!!!!! 最小限で動いたところでタグを切った。コードは下記リンク参照。 CircleCI上で、 「chefでdockerコンテナにcookし、それをserverspecでテストする」 を実現しています。 以下、ポイントなど CircleCIでdockerをどう準備するか 無理にapt-get -y install dockerとかやってインストールしても、docker psすら返ってこなくなる。 公式にサポートしてるserviceを使うとうまくいっ
CircleCIでgoverallsする - Qiita
前提 GitHubにGoのソースコードがある coveralls登録済み CircleCI登録済み GitHubでの作業 今回はCircleCI側のWebコンソール上で設定するので、circle.ymlは不要です。 Coverallsでの作業 ※特筆すべきことは無いので省略 CircleCIでの作業 Project Settingsを開きます Environment variables COVERALLS_TOKEN = XXXXXXXXXX ※XXXXXXXXXXはcoverallsで登録したTOKEN Test commands 今回の例は、github.com/kyokomi/go-docomoプロジェクトのgithub.com/kyokomi/go-docomo/docomoをtestしたいので以下のような設定になる。（最後の行の./docomo） go get github.co
Re:VIEWとDockerとCircleCIで原稿を継続的インテグレーション - orangain flavor
Re:VIEW で執筆する原稿を継続的インテグレーションしたかったので、以下の図のような仕組みを作りました。 ローカル執筆環境の前提条件 Docker 1.3以降がインストールされている Re:VIEW形式の原稿のフォルダがある Re:VIEWやLaTeXはDockerイメージのものを使うので、インストール不要です。 私はMac OS X 10.9とBoot2docker 1.4.1で動かしましたが、WindowsやLinuxでも動くのではないかと思います。 Re:VIEWをDockerで動かす vvakameさんがDocker Hubにイメージを公開してくれていますので、これを使います。 https://registry.hub.docker.com/u/vvakame/review/ dockerコマンドさえ使える状態であれば、以下のようにしてサンプル書籍 をコンパイルしてbook.p
Simple, free continuous integration (CI) of Rails Docker images using fig, make, and CircleCI
Programming, guns, ISP/telecom, rural life. Ex-farm boy This is my second post on Docker. Previously I showed you how I develop Rails apps locally using Docker and Vagrant on my development machine. I had planned to cover Rails production deployments using Docker next, but that post is not quite done as it got a lot longer than I originally intended and needs some editing. So for now, I’m going to
ChatOps時のブランチ運用戦略(実装 / コードレビュー / 関係者確認 / 自動テスト / デプロイを円滑に行う) - Qiita
*1 CircleCIによって、GitHub上の該当ブランチに変更があった場合に、自動でデプロイされる環境になります。 #Hubotの擬犬化 ここでは、Hubotを擬犬化して、ロボットではなくワンコとして扱っています。本投稿の挿入画像でも、Hubotではなくwankoとして表示されているので留意してください。 #実装からリリースまでの流れ ##①masterからブランチを切って、実装 新規ブランチをmasterから切り、実装を行います。 ##②仮コードレビュー[WIP]の実施（任意） 実装が終われば、検証環境へデプロイして関係者確認を行いますが、これの前にコードレビューを行います。ただしここでのコードレビューは必須ではありません。 この段階でのコードレビューが推奨されるのは以下の場合です。 修正が大規模なとき 検証環境での確認が終わり、masterにマージする際にレビューが入ります。ここで
CircleCI経由でRailsアプリをデプロイ - Qiita
machine: timezone: Asia/Tokyo ruby: version: 2.1.3 dependencies: pre: - sudo pip install awscli deployment: staging: branch: deploy-staging commands: - sh script/deploy-staging.sh: timeout: 1500 production: branch: deploy-production commands: - sh script/deploy-production.sh: timeout: 1500 CircleCIでのビルドは以下の6つののフェーズに分かれており、それを上記の設定ファイルに書いていくようだ。 machine checkout dependencies database test deploymen
CircleCIを使った継続的Webセキュリティテスト環境の構築 - クラウド型Web脆弱性診断ツール VAddyブログ
VAddyとCircleCIを組み合わせると、簡単に継続的セキュリティテスト環境が実現できます。 git pushするとCircleCIのジョブが起動し、テストサーバにコードをデプロイ、そのテストサーバに向けてVAddyからWebの脆弱性検査を実施します。 今回は、 git push -> Unit test -> Deploy(Staging) -> VAddy test -> Deploy(Production) という流れで解説します。 Unit testが失敗した場合は後続の処理は行われませんし、VAddy testが失敗した場合も本番にコードがデプロイされません。 こうして、ユニットテストとWeb脆弱性検査を定期的に実施して問題のないコードのみを本番環境にデプロイできます。 前提 この記事では、CircleCIインスタンス内に立てたWebサーバに対しての脆弱性検査ではなく、Cir
GAE/GoのWebアプリをCircleCIで自動テスト&自動デプロイする - Qiita
はじめに 以前投稿した「IntelliJ IDEAを使ってGAE/GoのHelloWorldする」のGAE/Goで作ったWebアプリを、CircleCIからGoogleAppEngineへdeployする手順の説明です。 前提条件・環境 GoogleAppEngineでアカウントが登録済み CircleCIでアカウント登録済み GAE/GoのWebアプリのリポジトリがGithubにある CircleCIの設定 プロジェクト直下にcircle.ymlを追加 今回は、appengineのバージョン1.9.12の例。 machine: timezone: Asia/Tokyo dependencies: pre: - curl -o $HOME/go_appengine_1.9.12.zip https://storage.googleapis.com/appengine-sdks/featur
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CircleCIの便利な機能 - Qiita
