CircleCIでdockerを使うときはバージョン指定を忘れないこと - モヒカンメモ
学び CircleCI上でdockerを動かすとデフォルトではバージョン17.09っていう化石エンジンで動いてしまうので気をつけるべし。 背景 とあるOSSアプリ のCIをCircleCIでしようと思って悪戦苦闘していたら、こういうリプを貰った。 よい子はちゃんとバージョン指定するんだぞ さもないとデフォルトで17.09が設定されちゃうぞ— 抽象構文木 (@ast988) March 21, 2019 「そんなバナナｗ 今は2019年だぜJK？ｗ」と思って確認したら、本当だったｗ ログ: https://circleci.com/gh/pinkumohikan/sunfish/21 新しいdocker engineを使う 積極的に新しいバージョンを使っていきましょうね、ということで circleci.com を参考に、こんな感じでバージョンを指定する。 すると、指定したバージョンでdock
【サーバーサイド一式】Docker + Rails + Circle CI + Terraformでインフラをコードで環境構築 & ECSへ自動コンテナデプロイ【前半】 - Qiita
様々なツールやサービスを繋げていく事は、全体像の把握がとても大事になってきます。 まず大きい流れを確認しましょう。時系列順に列挙すると以下となります。 ###アプリが自動でコンテナデプロイされるまでの流れ (0.TerraformでAWS上のリソースを定義) 1.RailsアプリをGithubにpush 2.CircleCIでCI開始 3.CIでDockerイメージをビルド 4.DockerイメージをECRへpush 5.ECSのTaskDefinitionを更新 6.CIでmigration 7.アプリがデプロイされる！ 画像に表すと、以下となります。 ざっくり各ツールの役割も解説すると ####terraform インフラストラクチャ定義ツール。 クラウド上のリソースを定義ファイルの状態になるように生成・操作してくれる。 画面上でポチポチやってたインフラの操作をコードにできる。 ###
CircleCI を使って Geppo のデプロイを劇的に改善しました | Geppoプロダクトブログ｜jaxx2104
以前 Geppo プロダクトブログで取り上げた「テスト環境増殖プロジェクト」によって、開発環境についてはインフラ基盤の刷新とCIの導入によって誰でも気軽にデプロイができるようになりました。ただ本番については未対応のままだったのと各ドメイン（サービス）が密結合だったので、昨日11月11日にリリースしたデプロイ基盤の改善について紹介したいと思います。 デプロイはどんなことが課題だったかまずは案件や障害対応といった業務をこなしていきながら、情報収集のために各メンバーに対してヒアリングをしながらインフラ構成図を最新化しました。あとはグループワークの時間を設けてバリューストリームマッピングをみんなで書いて Geppo の機能を顧客に届けるために必要なプロセスと改善点を可視化するなどしました。 バリューストリームマッピングによってプロセスと改善点を可視化 そこで出たのは以下のような課題でした ・デプロ
CircleCIから安全にAWSのプロダクション環境へデプロイする - Qiita
CircleCIから複数のAWSアカウント、たとえばステージング環境とプロダクション環境(本番環境)へ、安全にデプロイする方法を記載します。 課題 CircleCIはAWSのCodePipeline等より使い勝手が良いのでAWSのプロダクション環境へのデプロイに使いたい しかしステージング環境とプロダクション環境は別のAWSアカウントで構築しておりIAMのアクセスキーの切り替えが必要 そしてIAM権限をAWSの外に出すのはセキュリティ上の懸念がある 対策 別アカウントなので認証情報の切り替えが必要 => CircleCIのContextsを利用する IAM権限をAWSの外に出すのはセキュリティ懸念がある => 利用するときだけIAMアクセスキーを有効化する Slackから簡単にキーの有効/無効を切り替えられるようにしておきましょう 順に説明してゆきます。 ブランチごとにAWS認証情報を切り
[Go] CicleCI2.1でgo modのデータを共有しながら複数ジョブを実行する - My External Storage
GitHub上のGoのリポジトリに対して継続的インテグレーション(CI)を行なう場合、CircleCIやTravisCIを使うのが一般的だろう。 CicrcleCI2.1でGo Modulesを使いながらマルチJobを定義したWorkflowを定義する。 attach_workspaceを使ってジョブ間のデータ共有をするのにひと手間必要だった。 TL;DR CircleCI2.0はWorkflowを使って複数Jobを平行実行することができる save_cacheを使うとWorkflowを実行するたびにModuleをダウンロードせずに済む persist_to_workspaceを使うと各ジョブで毎回Moduleをダウンロードせずに済む attach_workspaceするときにuser:rootの設定が必要な場合がある めんどくさいときは@__timakin__さんのCircleCI Or
![[Go] CicleCI2.1でgo modのデータを共有しながら複数ジョブを実行する - My External Storage](https://cdn-ak-scissors.b.st-hatena.com/image/square/ac7859a2a946334ef6c8c8418904e531cef98374/height=288;version=1;width=512/https%3A%2F%2Fbudougumi0617.github.io%2Flogos%2Fcircleci.png)
reviewdogによるGoのコードレビュー - DeNA Testing Blog
こんにちは。ゲーム・エンターテインメント事業本部の鈴木です。 AndAppの開発をしています。 今回は私たちのチームで使っているreviewdogについて、CIの設定やlinterの組み合わせなど、どのようにしてコードレビューに活用しているか紹介します。 reviewdogとは 一言でいうとコードレビューを補助してくれるコマンドラインツールです。 各種linterの実行結果を渡してあげると、Pull Requestなどの差分に関して警告された行を教えてくれます。 私たちのチームではほとんどがGo言語による開発なため、golintなどの結果を表示するために使っています。 開発はGitHub Enterprise上で行なっており、CircleCI Enterpriseからreviewdogを実行すると以下のような警告がPull Requestのレビューコメントとして付きます。 似たようなツール
GAE/Go & CircleCI でカナリアリリースをする - Akatsuki Hackers Lab | 株式会社アカツキ（Akatsuki Inc.)
この記事はAkatsuki Advent Calendar 2018の12日目の記事です。 前回は hayamaruさんの、知覚メカニズムと網膜投影でした。 はじめに 継続的デリバリーという文脈で、素早く、安全にデプロイする手法について、近年多くの記事を見かけます。 例えば、カナリアのおかげで命拾い : CRE が現場で学んだこと でカナリアリリースについて詳しく触れられています。このアイデアは「たとえテスト環境で十分な検証をしたとしても、本番環境で問題が発生しないということを保証するのは難しいので、少しづつトラフィックを移動して問題があったらすぐにロールバックをしよう」というものです。 上記記事中に紹介されているKayentaといったツールを使ってカナリア分析を行い、自動的にカナリアリリースするというのも良いですが、人間による承認を元にデプロイするならもう少しコストの低い方法で良さそうで
いまさらだけどCircleCIに入門したので分かりやすくまとめてみた - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 今度入社する会社では、JenkinsでなくCircleCIを使っているということなので、1から勉強した内容を初心者向けにまとめました。 また、最新バージョン2.1(2018/12時点)の新機能も本記事では触れています。 ※2019/8/8追記 Slack連携に関する記事も書きました。 SlackでCircleCIからカバレッジレポート通知を受け取る設定手順 ※2020/4/2追記 https://twitter.com/CircleCIJapan/status/1245253320551399424 CircleCIさんより、
Djangoのテストの書き方とCircleCIを活用した継続的インテグレーション
今回の内容 前回はDjango 2.0での変更点を取り上げ、モデルの定義、Django REST frameworkの導入ついて解説しました。前回までのコードは以下から取得できます。 massa142/modern-django at volume2 第3回となる今回は、まず前回実装したViewに対するテストを取り上げます。Djangoの標準的なテストから始めて、サードパーティを利用したより実践的なテストの書き方を紹介します。その次に、実装したテストをCircleCIでの継続的インテグレーションに組み込みます。 テストの作成 前回Django REST frameworkのModelViewSetを用いて実装したkanban/board/views.pyの品質を担保するために、テストを書いてみましょう。 python manage.py startappを実行した際にtests.pyという
Google Apps Script のデプロイを Circle CI から行う - Qiita
次の記事でGASをローカル環境で開発するためのテンプレートを作りました。 Google Apps Script をローカル環境で快適に開発するためのテンプレートを作りました - Qiita ローカル開発ができるようになったら、次にほしいのはCI/CD環境ですよね。 テストが通らないコードをマージしたくないですよね。 マージされたと同時に自動でデプロイしたいですよね。 上記のテンプレートに Circle CI を設定したサンプルリポジトリを作ったので参考にしてみてください。 howdy39/gas-clasp-library ※このリポジトリはGASのライブラリ使用時のサンプルでもあります。（SlackAppを使っています） 本記事では Circle CI 使用時のCI/CD環境の構築手順を解説をしていきます。 clasp の仕組み 設定する前にまず clasp の仕組みを理解しましょう。
<mazgi.github.io 移行済>S3+CloudFrontをTerraformで設定してCircleCIで更新する - mazgi.log
移動しました=> mazgi.log :: S3 + CloudFrontをTerraformで設定してCircleCIで更新する 「TerraformでS3+CloudFront+SSL/TLS証明書 w/ ACMを設定してHugoで作ったstaticなWebサイトをCircleCIで自動deployする」やつができた。 できたもの 普通のいかにもHugoで作ったWebサイトができた。 もう2018年なので手オペなどせずInfrastructure as Codeで構築かつCIでコンテンツdeployです。 中身はまだない。 きっと酒とメシについての何かが書かれるのでしょう。 https://sakemeshi.love/ これはそもそも先日開催したハッカソンでやろうとして途中までしか進められなかったので、その補習も兼ねてます。 なお次回ハッカソンはGoです！ denatechstudi
iOSアプリをCircleCIにのせる - Qiita
Fastfile 基本fastlane initでできるものでOK .circleci/config.yml Project > Add Project > macOS > Setup Project からプロジェクトの設定を行う .circleci/config.ymlは基本sample.ymlでOK # iOS CircleCI 2.0 configuration file # # Check https://circleci.com/docs/2.0/ios-migrating-from-1-2/ for more details # version: 2 jobs: build: # Specify the Xcode version to use macos: xcode: "9.0" steps: - checkout - run: bundle install # Insta
既存のサービスを組み合わせて本質的な開発に集中する - star__hoshi's diary
qiita.com 個人開発アドベントカレンダー9日目です! (2週間遅れです... 🙏) 一年前に開発してた Web サービスで、このような構成の開発をしていました。 個人開発はとにかく時間が足りないので、既存のサービスを使える場合はそのサービスを使って開発を行いました。 開発していたものは結局リリースしなかったのですが、CI や SaaS を使い快適に開発できたので、使っていたサービスや構成について書いていきます。 これは個人開発での遊びであり、これで商用サービスもいけるかというとわかりません。 (それと私は iOS エンジニアであり、サーバサイドは門外漢です) サービス概要 Lastfm のような、音楽を再生したらその履歴をとって何回再生したか、いつどこで再生したかなどを自分が聞いた音楽を歴史として遡れるようなアプリを作っていた。 メインの技術スタックは Rails + Herok
CircleCI2.0 に移行してビルド実行速度を向上 | MEDLEY Developer Portal
2017-10-24CircleCI2.0 に移行してビルド実行速度を向上こんにちは。開発本部の稲本です。医療介護の求人サイト「ジョブメドレー」の開発を担当しているエンジニアです。 最近ジョブメドレーでは CircleCI2.0 への移行を行いました。移行の方法はもちろん、その際に調べたこと、CircleCI の新機能を利用してどうだったかなどを書いていきたいと思います。 課題感弊社では、全プロダクト(CLINICS、MEDLEY 、介護のほんね、ジョブメドレー)で CircleCI を利用しています。 ジョブメドレーでは CI によるテスト実行に 37 分前後掛かっていました(コンテナを 2 つ利用した実行時間です)。 さらに、開発メンバーが増えて来たこともあり、CI のリソースが足りなくなり開発効率が落ちかねない状況でした。 まぁよくある話ですよね。 コンテナを増やすというのも解決策の
CircleCI 2.0 で docker-compose を動かすなら、Machine Executor にしないとハマる - Qiita
CircleCI 2.0 で docker-compose を動かすなら、Machine Executor にしないとハマるCircleCIDocker 2017/09/12 追記 Circle CI 2.0 の docker executor が ECR に対応しました。 単純にECRのイメージを使いたいということだけであれば、もうこのページに書かれている machine executor を使う必要はないと思います。 CircleCI Blog - AWS EC2 Container Registry (ECR) Support 正しく動くものから 最後まで読まないと正解がわからないのはつらいと思うので、正解を最初に書くと、以下のようにすると問題なく動作する。 version: 2 jobs: build: machine: true steps: - checkout - run:
CircleCIでRailsのDockerコンテナをECSにデプロイする - UUUMエンジニアブログ
nazoです。 Graceful RestartによるRailsアプリのデプロイ を行っていたのですが、もっと手軽に環境ごとデプロイをしたいという需要もあって、Dockerを採用したデプロイも行っています。 CircleCI(1.0)では辛うじてDockerのサポートがありますが、いくつか癖があるので、ECSと含めて運用まで踏まえた手順について紹介したいと思います。 目的 AWS EC2 Container Service（以下 ECS ）を使用し、DockerコンテナをEC2にデプロイします。github.comにコードをpushしたら CircleCI 上で自動でビルド・テスト・デプロイが行われるようにします。 ECSを使う理由は、AWSへの依存をぎりぎり少ないところで手軽にDockerコンテナのデプロイを行いたかったというところです。ECSを使用することにより、簡単にDockerコン
2017 CircleCI Meetup Tokyo #2 が開催されました #circleci #circleci_meetup - tehepero note(・ω<)
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で行
CI環境におけるaws-cliのインストール結構つらいよね問題 - tehepero note(・ω<)
2017 - 03 - 04 CI環境におけるaws-cliのインストール結構つらいよね問題 AWS Docker ECR つらい 、というのはあくまでCircleCIとかでインス トール するときの話。 github.com 動機 今Docker Registryを Amazon ECRに移行していってるんですが、今までCI上でやっていたdocker build/docker tag/docker pushのプロセスをECRでも同様にやるために、 ecr get-login をする必要がある。 ecr get-login の正体はECRにdocker loginするためのコマンドを標準出力で返してくれるというもの。 $ aws ecr get-login --region ap-northeast-1 docker login -u AWS -p あなたのアクセストークン none ht
AWS Application Load Balancer + Amazon ECS でDockerのホットデプロイ環境を構築した - Glide Note
TL;DR AWS Application Load Balancer(以下ALB) + Amazon ECS でDockerのホットデプロイ環境を構築した ALBのTarget GroupとECSのServiceを紐付けることで、ALB配下のコンテナの入れ替えが自動で行われるようになる ALBは先日リリースされたばかりで、私もまだ色々と検証している段階なので、内容や認識等に誤りがあるかもしれないのでご容赦下さい。(詳しい人教えてください!!) その他弊社の前提情報 GitHub + CircleCIが連携済み Docker RepoにはAmazon EC2 Container Registry(以下ECR)を利用 DeployはGitHubのデプロイブランチへのマージを契機にCircleCI経由で、Docker Pushとecs-deployでDockerデプロイを実施 準備 ALBとE
Alpine LinuxなDockerイメージにServerspecを実行する環境を作った - Glide Note
TL;DR Alpine LinuxなDockerイメージにServerspecを実行する環境をMacとCircleCI上に作った CircleCI環境では lxc-attach コマンドが必要なので、spec_helper.rb で環境差を吸収するようにした 今後よく利用しそうなので、流用しやすい形でGithubに置いておいた glidenote/docker-alpine-serverspec-sample 前提 最近Kaizen Platform, Inc.で利用している一部Docker ImageをAmazon LinuxベースのものからAlpine Linuxベースのものに置き換え中。 Alpine Linuxについては@stormcat24さんのブログが一番参考になります。 今までDockerイメージにServerspecを実行するときには、コンテナ内でsshdを立てて、ssh
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
