2018-11-19追記 https://github.com/CircleCI-Public/circleci-dockerfiles/blob/master/ruby/images/ いつの間にか公開されてました 動機 circleciが提供しているdockerファイルで、rubyのバージョンとして、node, browswer , node-browsersとかがあった setup-projectしたときのデフォルトはnode-browsersだった 地味にsetup projectでボイラープレート出てくるのも知らなかった。。。 なんとなくフロント好きおじさんからするとnodeってバージョン何入ってるんだ!が気になった。 dockerの中身が見たい。 残念ながらDockerfileは公開されていないっぽい ここでdocker historyコマンドがあると知った。 $ docker
概要Docker + Ansible + ServerSpec + CircleCI 2.0でTDDなCIビルドを行う話です。 今僕が在籍している企業では、プロビジョニング周りはAWS OpsWorksで管理されており、Chefのカスタマイズレシピが適用されて、ポンっと環境が構築されます。 個人的にはChefとItamaeの運用はしたことがありますが、OpsWorksを除けばAnsibleの方がStar数も多く活発に使われていそうなのと、どうせならDockerとServerSpecを使ってポータブルなテスト環境を作ってみよう、それをCircleCI2.0で効率的に回そう、と思い立って、やってみました。 ディレクトリ構成. ├── Dockerfile ├── README.md ├── ansible │ ├── ansible.cfg │ ├── ci.yml │ ├── circlec
こんにちは。 かれこれ1年くらい仕事でCircleCI + Dockerを使ってみているのですが、 とにかくツラい 。 CircleCI + Docker構成でCIしたい方はだいぶマゾいとすら思います。 他のCI系のサービスどうなんだろうと調べつつも、これまで戦ってきたノウハウは備忘録として残そうと思います。 なにがツラいかというと、 btrfs(B木ファイルシステム)というファイルシステム上に 独自にforkしたDockerを積んでおり のと、CIで使用するイメージに色々カスタマイズが入っている(調べきれていない) という構成だと、色々なDockerに関する操作が動きません。 ローカルでは動くので、基本ドはまりする要素満載です。 さらにdocker-composeでブラックボックスに包むと、余計にわけがわからなくなります。 ということでハマったことと、CircleCIでDockerを扱う
先日素振りがてら、個人の小さな Rails リポジトリを Dockerize しました。 https://github.com/masutaka/github-organization-watcher/pull/45 現在クローズドβの CircleCI 2.0 は Docker 前提らしいので、これも素 振りがてら移行してみました。 https://github.com/masutaka/github-organization-watcher/pull/48 CircleCI 2.0 はここから申請すれば、すぐ使えるようです。 https://circleci.com/beta-access/#request-access 移行前の印象# (1) 1.0 では宜しくやってくれたけど、2.0 は circle.yml に全部書く必 要があるみたい。面倒そう。 (2) とは言え、Docker
⠀人 / ⁰⊖⁰ \ オカメインコエンジニアの五十嵐(@ganta0087)です。 CrowdWorksでは、サービスのCI環境としてCirlceCIを利用しています。 今回、CircleCI 1.0から2.0に移行すると同時に、新機能のキャッシュをフル活用したことで、コストを増加させることなくCI実行時間を半分にすることができました。 今回の記事では、CirlceCI 2.0のメリットや、どのようなチューニングを行ったのかをご紹介します。 CircleCI 2.0について CircleCI 2.0は現在ベータ版となっており、「CircleCI 2.0: Beta Access - CircleCI」から申し込むことができます。(試してみたところ個人のリポジトリではすぐに利用できるようです。) 申請したOrganizationのすべてのプロジェクトで突然バージョンが切り替わるわけではなく、
CircleCI 1.0ではDockerのバージョンが1.10.0まででしたがCircleCI 2.0では最新のDockerを使用することができるようになりました CircleCI 2.0にDockerをインストールする 流れとしては以下のようになります 作業用のDockerコンテナを選択する remote dockerをセットアップする docker clientをインストールする circle.ymlに書き起こすとこのようになります version: 2 jobs: build: working_directory: /go/src/github.com/ieee0824/circleci-demo docker: - image: golang:latest steps: - checkout - setup_remote_docker - run: name: install Do
At BKNO3 we use Docker and docker-compose for development, in order to make sure every developer can easily and reliably set up a development environment locally, even if they're not familiar with the project itself (we have several components, with different developers working on each one). The same docker containers are used to run continuous integration (on CircleCI) as well, in order to reduce
CircleCI v1の話です、v2.0になったらもうちょっと楽になってそう(未確認) 基本的には以下のページを参考にしてます。 Caching docker image on CircleCI 1. キャッシュ用のディレクトリを用意する 例えば ~/docker-images、これを circle.yml の cache_directories に追加しておく dependencies: cache_directories: - "~/docker-images" 2. イメージのタグを生成する Dockerfile と依存ファイル達の sha1sum を取る。 たとえばRailsアプリの場合、gemだけイメージに含めるなら Gemfile と Gemfile.lock これらに変更が無ければ同じ値になるはず。(なのでキャッシュが使えるはず) tag=$(sha1sum Dockerfi
2017 - 03 - 11 2017 CircleCI Meetup Tokyo #2 が開催されました #circleci #circleci_meetup CircleCI CI DevOps 昨日3/10、弊社にて2度目のCircleCI Meetupが開催されました。 cyberagent.connpass.com CircleCI 2.0について CircleCI社よりDeveloperのKim氏にご登壇頂き、現在クローズドベータ公開中であるCircleCI2.0について発表していただきました。 1.0問題 ビルドイメージが Ubuntu のみで、Dockerコンテナ上でのビルドにも未対応 LXCのprivileged問題(Dockerは特権保持していないLXCコンテナ上で動作させることはできない)を突破するために、Dockerにパッチを当てて運用していたがこの手法は1.9で行
はじめまして(?)。taiyohと申します。 幾つか事業部を渡り歩いた後、現在はLobiにて新規機能の開発などを行っております。 皆様は3/3発売のNintendo Switchの予約はお済みでしょうか。僕は早速1/21の午前中に近所の電器店に駆け込んで予約をしました。ゼルダ、Splatoon2、ゼノブレイド2と、既にやりたいソフトがいくつかあるので大変楽しみです。2017年も何とか生きていけそうです。どうぞ宜しくお願いします。 さて、昨年の2016年末ですが、Lobiアカウントを利用したトーナメントサイトというものをリリースしましたので、そのちょっと技術っぽい観点についてお話させていただきます。なお、技術っぽいと書きながら実装やインフラ成分は低めです。その点予めご了承ください。 Lobiトーナメントはゲーム大会をより簡単に開催・参加できるようにしたサービスです。大会のエントリーから大会終
App Service on Linux での Docker 対応は Azure Container Service などに比べて、お手軽なので非常に便利なんですが、Elastic Beanstalk のように Dockerfile を含むリポジトリから自動的にビルドをしてくれないので、必然的に何らかの方法で Docker Image を作成する必要があります。 Windows Server Containers な PaaS がリリースされても同じような流れが必要になると思うので、簡単に必要な流れを確認しておくことにしました。単純に Docker を使った CI/CD に興味があったとも言います。 ASP.NET Core アプリケーションをプリコンパイル プリコンパイル結果を利用して Docker Image を作成 Docker Hub にプッシュ App Service on Li
2017/04 追記 CircleCI 2.0 で Docker のバージョンが上がったためキャッシュできるようになりました 以下は CircleCI 1.0 時代になぜできなかったのかの説明 やりたいこと CircleCI の Docker イメージビルドが遅い イメージキャッシュが引き継がれないため なんとかしてイメージキャッシュを引き継ぎたい TL;DR CircleCI の Docker バージョンが 1.10 の間は、無理 もう少しでなにかしらのアナウンスがあるらしい (https://discuss.circleci.com/t/request-docker-1-12/5120/13) Docker 1.11 対応を待つ tonistiigi/buildcache が使える Docker 1.13 リリース & 対応を待つ cache-from オプションが追加された Circ
CIツール勉強会@福岡 (http://connpass.com/event/12120/) で、Circle CIの話しを発表したRead less
コンニチハ、最近Dockerを沢山使っている千葉です。今回はDockerを使った継続的インテグレーションやデプロイを試してみました。 継続的インテグレーションは一度導入すると破壊力抜群でとても効率的な開発ができるようになるため、これを機会に試してみたいと思います! CircleCI+ECS+ECR環境を使ってDockerコンテナを継続的デプロイする環境を作ってみました。初めての方でも雰囲気つかめるように、ECR,ECSのセットアップからCircleCIのセットアップまで一通りやろうと思います! 動作としては以下のようになります。図にするとこんな感じです。 GitHub上にECRへのデプロイ用のシェル、CircleCI用の設定ファイル、Dockerfile、コンテンツ(index.html)をpushする GitHubへのpushをトリガーに、CircleCI上でDockerfileよりコン
2015-02-04 CircleCIでDockerイメージをキャッシュするのに、実はちょっとした工夫が必要な件 CircleCI Docker 2月ですね。 さて、CircleCIにはcache_directoriesという機能があって、前回のビルドでダウンロードしたり生成したりするもので時間的コストのかかるものをキャッシュしておいて、次回以降のビルドでコンテナにリストアできます。 例えば、MavenでJarを大量にダウンロードしてきて出来上がったローカルリポジトリ等ですね。ちなみに.m2や.ivy等はデフォルトでキャッシュされます。 Dockerイメージのキャッシュ ライブラリの他に、時間的コストとなるものの代表というとやはりDockerイメージなんですけど、実はこれをcache_directoriesの機能を使ってイメージの場所を指定してもビルドの時間は短縮できません。 実はCirc
概要 もう随分と前に TravisCI から CircleCI へ乗り換えたのですが、いかんせん、便利な CircleCI をもってしても Android のプロジェクトのビルド時間は長くなり続け、ついに 1 回のビルドに 20 分を費やすほどにまで成長してしまいました。いくつか無駄を省いたり、キャッシュをしてみたりと言った策を講じたものの、目立った改善が得られませんでした。そこで CircleCI を脱却してみることにしました。現在、CircleCI を脱却し Wercker を利用することで 1 回のビルドが 5 分ほどで終わるようになりました。この記事には、何がどのようにして短時間で済むようになったかを書き記してあります。 問題の根源 そもそも CircleCI で時間がかかっている部分はどこかというところから見ていきます。現在のプロジェクトで使用している分には、以下に上げる部分でか
前回、「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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く