Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
はじめに AWSでDocker環境を構築するとき、今までまず選択肢としてあったのがAWS Elastic BeanstalkやAmazon ECSでした。 ですが皆様ご存知の通り、2018年の7月にAWS Fargateが東京リージョンで利用できるようになりました! Docker環境の選択肢が増え嬉しい限りです。 ということで、少々出遅れてしまいましたがAWS Fargate + Terraform構成を本格的に業務で使ってみることにしました。 ※ ちなみに、AWS Fargateは独立したサービスではなくAmazon ECSの中に組み込まれており、launch typeで「Fargate」を指定することにより利用できるサービスとなります。 よくネット上で「AWS FargateとAmazon ECSの違い」みたいな記事を目にしていたので別サービスだと勘違いしてました… 1. 最強のTer
はじめに CircleCI便利ですね。 テスト結果をGitにコミットしてもらうようにしました。 今回はテスト結果ということで、それぐらいだったらCircleの画面で見ればいいじゃない、って感じなんですが、もっと重いE2Eの結果をスクショで取って専用のブランチにコミットしてもらったり、Cronでスケジュールを走らせて自動コミットできて便利でした。 手順 CircleCI用のconfigを書く # Javascript Node CircleCI 2.0 configuration file version: 2 defaults: &defaults working_directory: ~/repo docker: - image: circleci/node:8.9.1 jobs: build: <<: *defaults steps: - checkout - restore_cach
前提 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
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_TOT
RailsをAPIサーバにしてクライアントコードをRailsとは完全に切り離してAngularJSで構築しているプロジェクトにおいてテストを自動化するためにCircleCIを使っています。 そこで、カバレッジを出力するのにrspecの場合は下記を参照して簡単にできるのですが、クライアントコードのカバレッジの出力に若干工夫が必要だったので、ここで簡単にやり方をご紹介します。 上記のURLだと"../../../"でカバレッジのHTMLの出力先を指定しており、これだとややっこしいのでディレクトリをデフォルトの出力先ディレクトリを変更しました。 また、上記のrspecの場合は、spec_helper.rbでCircleCI環境時に出力先を指定しているのですが、karmaでは開発時に使用しているgruntのtestとは別にCircleCI用にtest:ciというタスクを用意して、CircleCI用
こんにちは、CircleCI Advent Calendar 18日目担当のKimです。 今回はCircleCIのTech stackと活躍しているツールについて紹介したいと思います。 開発系 Clojure CircleCIといえばご存知Clojureです。最初はRubyとRoRを使ってたみたいですが途中で切り替えた様です。Clojureを本格的に使ってるチームはまだまだ少ないと思います。個人的にはClojureがやってみたくてCircleCIに入ったという部分は大きいです。 起動が遅いとか、エラーメッセージが結構な割合で意味不明とか、関数言語としては怪しい仕様が時々あるとか、色々細かい不満はありますが基本的にはみんなClojureを愛しています。 ClojureScript フロントエンド開発ではClojureScriptを使っています。フロントエンドはほとんど触らないのであんまり詳し
概要 CircleCI と Serverless を使ったサービスの開発環境の雛形。 はじめに 新しくサービスを作ることになりまして、 Serverless を使うことにします。 Serverless: https://github.com/serverless/serverless CircleCI で自動的にテスト、 AWS にデプロイするようにしておきます。 CircleCI: https://circleci.com/ Github で雛形を公開します。 https://github.com/exabugs/circleci 雛形を使って最短でプロジェクトを立ち上げる手順を以下で示します。 最短で試すには アカウント作成 AWS Github CircleCI Github から clone Fork git clone https://github.com/exabugs/cir
CircleCI で GKE(Google Container Engine) にデプロイしようと思っても、(案の定)現状のドキュメントのままやってもうまくいかないところがあります。その辺りのポイントをまとめます。 ベースとなるドキュメント Docker を利用する部分は、ここをベースに作ります。Kubernetes を使う部分は、GCE(Google Compute Engine) に Kubernetes をインストールして導入する手順となっているので、このまま使えません。GKE の場合は、もっと簡単に使うことができます。 GCP との連携 GCP(Google Cloud Platform) の CLI である gcloud コマンドは、既に導入された状態になっていますが、操作するためには認証を通す必要があります。この辺は、このドキュメントのまま使えます。 set project す
今回は上記の図の中に、オレンジ色の枠線に囲まれている部分の設定方法を紹介したいと思います。 CircleCIからHerokuにデプロイする作業が非常に楽で、「PROJECT SETTINGS」の「Heroku Deployment」に従ってやれば基本的に問題ありませんが、AWS CodeDeployの場合、かなり面倒いです。 S3側 リビジョンを保存するバケットを確保します 出来れば新しいバケットを作った方が楽ですね。 ロケーション(Location)は「s3://<バケット名>/」ですので、 仮にバケット名をdummyにすれば、「s3://dummy/」になります。 IAM(Identity and Access Management)側 CodeDeploy用のIAMロールを作ります CodeDeployが出来ることは、S3上のリビジョンを特定の条件(某タグがある)を満たす全てのEC2
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く