はてなブックマーク

前提条件: Deployment を使ってアプリケーションのデプロイ管理を行っている tl;dr PodTemplateSpec の Label か Annotation (.spec.template.metadata.[labels|annotations]) に適当な key-value を追加・上書きする。 value はタイムスタンプにでもしておくと便利。 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: awesome-app labels: name: awesome-app role: web spec: minReadySeconds: 30 strategy: type: RollingUpdate rollingUpdate: maxSurge: 50% maxUnavailable: 0

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

$ curl -s https://api.github.com/repos/dtan4/s3url/releases | jq -r '.[0].assets[] | select(.name | test("linux-amd64.tar.gz")) | .browser_download_url' https://github.com/dtan4/s3url/releases/download/v0.3.1/s3url-v0.3.1-linux-amd64.tar.gz サーバに Go バイナリを配置していて定期的に更新したい場合は、このワンライナーと展開処理を行うスクリプトを cron とかで回しておけばよさそうです。 curl -s https://api.github.com/repos/dtan4/s3url/releases dtan4/s3url リポジトリの Relea

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Go でツール書くときはタスクランナーとして make を使っています。ビルドだけじゃなくて、テストや配布用パッケージ作成も一括して make でやっています。 今回は整理も兼ねて、自分が普段どういう Makefile を使っているのか解剖していきます。 なぜ make を使うのか ビルドフラグ覚えるのが面倒だから、make は (Windows を除く) 大半のプラットフォームに入っていて使いやすいからというのが理由です。script/build みたいにシェルスクリプトを複数用意するのでもまあ良いと思いますが…。大半の Go プロジェクトは Makefile 置いてありますね。 make を使った開発フロー 基本的には、リポジトリを git clone / go get -d した後に以下のコマンドを打てばアプリケーションをインストールできるようにしています。

Travis CI から GitHub Releases にアップロードする Go などのコンパイラ言語で書いたソフトウェアを配布する場所として、最近は GitHub Releases を使うことが多いと思います。単純に Git tag と紐付けてファイルをアップロードする場所ですが、手作業でやるのも面倒なので CI と連携させるのが便利です。 Travis CI には Deployment の機能があります。その名の通り、アプリケーションのテスト/ビルド後に、外部の指定した場所へ成果物をデプロイする機能です。デプロイするトリガーとして「特定のブランチ」「git tag がプッシュされた場合のみ」「Go 1.7 ビルドのみ」のような条件が指定できます。 Deployment は、標準で GitHub Releases のインテグレーションを備えています (GitHub Releases U

The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale "en_US.utf8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". ... LOG: autovacuum launcher shutting down LOG: shutting down LOG: database syste

この記事は、RubyGem 開発速習会@Wantedly の資料として作られたものです この資料は、 Ruby 2.3.1 RubyGems 2.5.1 Bundler 1.12.4 の環境で執筆されました。 この速習会のゴール gem を一から作れるようになる ただ作るだけじゃなく、テスト駆動開発を取り入れた効率のよい開発ができるようにある 開発支援系のサービスに詳しくなる gem とは gem は、最もメジャーな Ruby ライブラリの形式です。 Ruby on Rails も1つの gem として提供されており、rails gem の中でもまた多くの gem が利用されています。 現在公開されている Ruby のソフトウェアや Ruby on Rails 上の Web サービスは、多くの gem を組み合わせることで成り立っているのです。 ちなみに www.wantedly.com

2016/11/15 10:15 追記 この記事では kubernetes/kubernetes リポジトリに含まれているクライアントライブラリを紹介していますが、今年の8月だか9月になって API クライアントだけが別リポジトリとして切り出されました。 今後何かツールを作るときは、この client-go を使うのがよいでしょう。 というわけで、以下の内容は__記事初公開時点の、client-go がなかった時代の__ものとなっております。その点ご留意いただいた上でお読みください。 追記終わり あまり知られてないようですが、Kubernetes には公式の Go 製 API クライアントライブラリがあります。kubectl もこのライブラリを用いて実装されています。 kubectl は確かに万能なんですが、実運用に投入するとなるとその万能さがマイナスに効いてくることもあります。で、自分た

プライベートリポジトリの CI 無料でお馴染みの wercker が、先日ワークフロー機能 Wercker Workflows をリリースしました。 とりあえず、以下の公式デモ動画を観れば何ができるのかわかると思います。 ブログ記事 Introducing Wercker Workflows デモ動画 Wercker Workflows - YouTube Wercker Workflows とは いわゆるワークフロー機能というやつで、1つの CI プロセスを複数のパイプラインに分割して組み合わせる機能です。Jenkins とか、最近だと Concourse CI でお馴染みの機能です。 パイプラインは従来の build, deploy に相当するもので、1つの CI プロセス内におけるタスクの分割単位となります。従来は build, deploy の2つしか記述できなかったところ、tes

スリムな Docker イメージを作るため、gliderlabs/alpine イメージをベースにバイナリを一個だけポンと置いて運用するみたいなことをしています。 gliderlabs/alpine イメージは（というかほとんどの OS イメージは）タイムゾーンが GMT (UTC+0) のままなので、時刻依存の作業をさせるときには気をつけないといけません。日本時間 (UTC+9) の感覚で書いたら、9時間遅れて実行されたとかログの時刻がずれるとか起こりえます。 まっさらの状態で date を打つと…

以下、emacs の部分は、あなたの Emacs 利用形態（新しい Emacs ではなくすでに起動している Emacs 上で開くとか）に合わせて emacsclient -n とかにしてください。 ターミナルから行番号を指定して開く Emacs のコマンドラインヘルプを見ると… $ emacs --help Usage: /usr/local/opt/emacs-mac/bin/emacs [OPTION-OR-FILENAME]... Run Emacs, the extensible, customizable, self-documenting real-time display editor. The recommended way to start Emacs for normal editing is with no options at all. (snip) Action

すればすぐ何もなかったことにできます。 が！そこで気付かずに GitHub へ git push してしまった！こうなると容易に何もなかったことにはできません。 この記事では、こういうときに何もなかったことにする方法を紹介します。 そのデータを無効にする 特に Public Repository の場合はすでにそのデータが他人の目に触れていた…ということも十分ありえます。AWS_SECRET_ACCESS_KEY なんかは取得用のクローラが存在するとも聞きます。ので、まずは不正利用されても影響が出ないように、__パスワードの書き換えやトークンの無効化__を施しましょう。 （この時点でもう何もなかったことになってない気がする） git の履歴から該当のファイルを消す git reset と git filter-branch 2つの方法があります。 git reset (2015-12-29

Wantedly Advent Calendar 2015 __18__日目です。 インフラチームインターンの @dtan4 です。 Wantedly では Terraform を用いたインフラのコード化 (Infrastructure as Code) を全面的に取り入れています。インフラリソースの追加や修正は、コードを書くこと・CI 上での自動適用によって行われています。 この記事では、今年5月から半年以上の間 Terraform を運用してきた中での なぜ Terraform でインフラをコード化しようとしたのか どのように Terraform を運用しているのか Terraform 運用にあたって注意すべき点 既存リソースから Terraform コードを生成する Terraforming について ということを紹介したいと思います。 Terraform とは Terraform

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 私は今まで、数々のアプリケーションやライブラリをつくって GitHub / RubyGems 等で公開してきました。ここで毎回注意しているのが__プロダクトの名前の付け方__です。この記事では、自分が何に気をつけて名付けをしているのかを紹介します。 ユニークな名前にする ユニークな名前にする、つまり__既に公開されているものとなるべく名前が被らないようにすべき__です。ユニークな名前にすることでググラビリティ（検索した時のヒットしやすさ）を高めることができますし、エゴサーチもしやすくなります。 同じ名前のプロダクトがすでに存在しないかチ

最近の GitHub に上げてある OSS リポジトリには、README にいろんなバッジが貼られています。リポジトリに連携しているクラウドサービスのステータスを表すものがほとんどです。 自分は README にバッジを貼りたい派です。たとえば dtan4/terraforming だとこういう感じです。 最近はバッジの種類も増えているので、整理のためにもどういうのがあるかまとめてみようと思います。 自分がよく README に貼っているバッジ 自分が書く RubyGems については、以下の6個のバッジを必ずつけるようにしています。 Travis CI 言わずと知れた CI サービス。現在の master が CI 通っている (passing) かコケている (failed) かがわかります。リポジトリのメンテナンス状況を把握するのによいです。 クリックすれば、そのリポジトリのテスト結

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

2017-06-17: この記事はもう古いです。Terraform v0.8.x 以下を対象としています。 2017/03 にリリースされた Terraform v0.9.0 で remote config 周りの仕様が大きく変わりました。 S3 に置くファイル形式は変わってないですが、特に CLI 周りで後方互換性のない変更が入っています。例えば terraform remote コマンドが無くなっています。 詳しくは以下の公式ドキュメントを読んで下さい。 Backends - Terraform by HashiCorp Backends: Migrating From 0.8.x and Earlier - Terraform by HashiCorp というわけで、以下の記事は Terraform v0.8.x 以下を対象としたものになります。 2015-05-08 にリリースされ

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Docker container で nginx を起動するときとか、nginx.conf で何かしらのパラメータを動的に設定したいことがあると思います。server_name とか。 今回は nginx.conf で何とかして環境変数を読み込む手法を紹介します。 TL;DR __env ディレクティブ__と ngx_http_perl_module (or lua_nginx_module) を使って、環境変数を nginx 変数に設定する。 Example server_name を環境変数 SERVER_NAME から動的に読み込む例を示します。 user nginx; worker_processes 4; env SERVER_NAME; http { perl_set $server_name_from_env 'sub { return $ENV{"SERVER_NAME"}

Travis CI には MeCab が入っていない Travis CI の box には最初 MeCab が入っていません。 こういう場合、普通なら .travis.yml の before_install を用いて以下のように MeCab をインストールするでしょう。 しかし、Travis の apt-get で入ってくる MeCab は古い (0.98) ので、例えば natto gem を使うようなアプリケーションが実行できません。 これでは Travis が赤くなって困るので、何とかして最新版 (2014/05/31 現在 0.996) を入れたいところです。 解決策: apt-get を使わず直にインストールする 最新の MeCab ソースコードを公式 Google Code から落としてきて、自家ビルド & インストールすれば良いのです。 基本的に公式インストールガイドの通り

==> ./b2 --prefix=/usr/local/Cellar/boost/1.55.0_1 --libdir=/usr/local/Cellar/boost/ cp "bin.v2/libs/wave/build/darwin-4.2.1/release/link-static/libboost_wave.a" "/usr/local/Cellar/boost/1.55.0_1/lib/libboost_wave.a" ...failed updating 112 targets... ...skipped 20 targets... ...updated 12489 targets... READ THIS: https://github.com/Homebrew/homebrew/wiki/troubleshooting These open issues may also

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?