Waypointとは何か
Hashicorpの2020年冬の新作 Waypoint (リリースブログ)に関してドキュメントなどをざっと眺めてみたので最初の印象をちょっと書いてみる．ちゃんとしたレビューは @copyconstruct の記事 Waypoint とか読むのが良い．毎度のことながらドキュメントやガイドはかなりちゃんとしたのがあるので使い方とかはそっちを読んだ方がいい．以下に書くのはざっくりした個人の感想（ちなみにもう一つのBoundaryに関してはZero Touch Productionとは何か に軽く書いた）． What is Waypoint Waypointは，KubernetesやNomad，Amazon ECS，Google Cloud RunといったPlatformの上にBuild，DeployとReleaseの一貫したWorkflowを実現するツール．使ってる言語やそのパッケージ方法や，
なぜMicroservicesか?
現職においてMonolithアーキテクチャからMicroservicesアーキテクチャへの移行とその基盤の構築に関わって2年近くが経った．未だ道半ばであるがこれまでの経験や日々のインプットをもとにいろいろ書いておこうという気持ちになった．本記事ではそもそもMicroservicesアーキテクチャとは何かを整理し，なぜやるべきか?・なぜ避けるべきかを整理する． Microservices? Microservicesアーキテクチャとは「Single purpose，High cohesion，そしてLoosly Couploedなサービスを組み合わせてシステムを構築する」アーキテクチャ手法である．それぞれの原則をまとめると以下のようになる． Single purpose: 一つのことに集中しておりそれをうまくやること Loose coupling: サービスは依存するサービスについて最小限の
"Microservices"を読んだ
James Lewis氏とMartin Fowler氏による“Microservices”を読んだ．以前ざっと目を通したが，最近よく耳にするようになったのでちゃんと読んだ．以下はそのメモ． 概要 “Microservices” とはソフトウェアシステムの開発スタイルである 近年このスタイルでの開発を見てきて良い結果が出ている 初出は2012年の3月の“Micro services - Java, the Unix Way” Microserviceは一連の小さなサービスで1つのアプリケーションを開発する手法 それぞれのサービスは自身のプロセスで動いており，軽量な機構（e.g., HTTP API）を通じて情報をやりとりする これらのサービスは独立して自動デプロイされる 一枚岩として構築されるMonolithicスタイルのアプリケーションと比較すると分かりやすい 一般的なエンタープライズのア
Dockerの諸問題とRocket登場の経緯
2014年の後半あたりからDocker，Docker Inc.への批判を多く見かけるようになった（もちろんもともと懸念や嫌悪を表明するひとはいた）．それを象徴する出来事としてCoreOSチームによる新しいコンテナのRuntimeであるRocketのリリースと，オープンなアプリケーションコンテナの仕様の策定を目指したApp Containerプロジェクトの開始があった． CoreOS is building a container runtime, Rocket 批判は，セキュリティであったり，ドキュメントされていない謎の仕様やバグだったり，コミュニティの運営だったり，と多方面にわたる．これらは具体的にどういうことなのか？なぜRocketが必要なのか？は具体的に整理されていないと思う．これらは，今後コンテナ技術を使っていく上で，オーケストレーションとかと同じくらい重要な部分だと思うので，ここ
Dockerコンテナ間のlink，database.ymlの書き方
Dockerコンテナ間のlink，database.ymlの書き方 DockerはLinksというコンテナ同士の連携を簡単に行う仕組みをもつ． これは，DB用のコンテナとアプリケーション用のコンテナの連携を行いたいときなどに有用になる． 例えば，1337ポートがEXPOSEされたcontainer1という名前のコンテナとの連携を行いたいとする． このとき以下のように，-link 連携したいコンテナ名:エイリアス名で新しいコンテナを起動すると， そのコンテナ内に連携したいコンテナのポート番号やIPをもった環境変数が現れる． docker run -d -link container1:alias user/sample bash root@48408a38c9b2:/# env ALIAS_PORT_5432_TCP_ADDR=172.17.0.2 ALIAS_PORT=tcp://172.
複数プロジェクトを抱えるチームでのデプロイ自動化
複数プロジェクトを抱えるチームでのデプロイ自動化 1つのチームで，10以上のプロジェクト，コードベースを抱える場合にどのようにデプロイの自動化を進めたか，工夫したこと，考慮したことなどをまとめておく． デプロイツールには，Python製のfabricを採用しているが，他のツールでも同様のことはできそう．なお，fabricの基本的な使い方などは既にインターネット上に良い記事がたくさんあるので書かない（最後の参考の項を見てください）． fabricの選択 シェルスクリプトとCapistranoを考慮した． まず，シェルスクリプトは人によって書き方が違うため，統一が難しくメンテナンスコストも高い．また共通化も難しい． 次に，Capistranoは，裏でやってくれることが多く，学習コストも高い．プロジェクトによってはかなり特殊な環境へのデプロイも抱えているため，Capistranoの前提から外れる
わかりやすいREADME.mdを書く
GitHubなどに自分のツールやライブラリを公開するとき，README.mdは重要な役割を担っている．レポジトリを訪れたユーザが自分のツールを使ってくれるか否かの第一歩はREADME.mdにかかっている，と言っても過言ではない．実際自分が使う側になったときも，まずREADME.mdを読んで判断していると思う． 成功しているプロジェクトを参考にしつつ，自分が実践していることをまとめておく．ここに書いていることはあくまで（自分の中で）最低限的なものである．プロジェクトが成長していくにつれてREADMEはあるべき姿に成長していくべきだと思う． READMEの役割 README.mdには大きく2つの役割がある． プロジェクト，ツールの使い方，インストール方法 プロジェクト，ツールの宣伝 元々READMEは前者の役割しかなかったが，GitHubの仕組み上，後者の役割も徐々に重要になっている． さらに
使いやすいシェルスクリプトを書く
できればシェルスクリプトなんて書きたくないんだけど，まだまだ書く機会は多い．シェル芸やワンライナーのような凝ったことではなく，他のひとが使いやすいシェルスクリプトを書くために自分が実践していることをまとめておく． ヘルプメッセージ 書いてるシェルスクリプトが使い捨てではなく何度も使うものである場合は，本体を書き始める前に，そのスクリプトの使い方を表示するusage関数を書いてしまう． これを書いておくと，後々チームへ共有がしやすくなる．とりあえずusage見てくださいと言える．また，あらかじめ書くことで，単なるシェルスクリプトであっても自分の中で動作を整理してから書き始めることができる．関数として書くのは，usageを表示してあげるとよい場面がいくつかあり，使い回すことができるため． 以下のように書く． function usage { cat <<EOF $(basename ${0})
DotenvではなくDirenvを使う
DotenvではなくDirenvを使う Dotenvは，.envファイルから環境変数を読み込むためのツール．他人には共有したくないパスワードやキーなどを.envに環境変数として記述しておき，実行時にそれを読み込むといった使い方をする．例えば自分は，vagrantからDigitalOceanを使う際に，CLIENT_IDやAPI_KEYを.envに記述してVagrantfileでそれを読み込むという使い方をしていた． ただ，Dotenvは汎用性が低い．Dotenvを有効にするには，プログラム内から明示的にDotenv.loadを呼ぶ必要がある，もしくは，dotenvでプログラムを起動する必要がある．例えば，test-kitchenのdigitaloceanドライバーを使う際には，vagrantの場合と同様にCLIENT_IDやAPI_KEYが必要になる．しかし，test-kitchenでユー
Dockerとは何か？どこで使うべきか？
この記事はDockerに関する実験的な記事や，Buildpackを使ってHeroku AppをDocker Containerとして使えるようにする“building”の開発などで知られるCenturyLink Labsの “What is Docker and When To Use It”の翻訳です． Dockerとは何か？Dockerをどこで使うべきか？についてよく見かける記事とは違った視点から説明されています． 翻訳は許可をとった上で行っています． Dockerとは何でないか Dockerとは何かを説明する前に，Dockerは何でないかについて述べる．Dockerの否定形は何か？Dockerの制限は何か？Dockerが得意でないことは何か？ DockerはLXCのようなLinux Containerではない DockerはLXCだけのラッパーではない（理論的には仮想マシンも管理でき
gitshでgitのタイプ数を減らす
gitshでgitのタイプ数を減らす gitはサブコマンドやオプションが多い．だからshellのaliasやらgitのaliasで頑張ってコマンドのタイプ数を減らす．Thoughbotの@georgebrockさんのgitshを使えばもっとコマンドのタイプ数を減らすことができる． 例えば以下はよく打つコマンド．gitって打ち過ぎ． $ git status $ git add -u $ git commit -m "Commit message" $ git push gitshを使うと専用のモードへのアタッチが始まり，gitを打たずサブコマンドだけを打てばよくなる． $ gitsh gitsh@ status gitsh@ add -u gitsh@ commit -m "Commit message" gitsh@ push gitsh@ :exit gitのaliasも引き継がれるの
BrewfileでHomebrewパッケージを管理する
BrewfileでHomebrewパッケージを管理する この記事は1分で実現できる有用な技術 Advent Calendar 2013の24日目の記事です． Brewfileを使えば，Bundlerでrubygemsを管理するようにHomebrewのパッケージを管理できる．Brewfileのあるディレクトリで $ brew bundle とすれば，Brewfileに書かれたパッケージがすべてインストールされる．これはHomebrew公式のコマンドであり，特別なインストール等は必要なく，最新版にアップデートすればすぐに使うことができる． これを使えば，dotfilesに加えて自分のbrewパッケージを管理しておくこともできるし（tcnksm/dotfiles/Brewfile），imagemagickのようにプロジェクトで必要になるパッケージをBrewfileとして共有しておくこともできる．
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
