iii threetreeslight

April 30, 2018

build hugo on ci

deployに備えてblogのci環境を構築する。 stackshare - ci を見る限りcircleciがshare的にも無難。 とはいえ、使い慣れたツールっていうのも味気ないが、将来的にはconcourse ci に載せ替えるとしてとりあえずはcircleciを利用する。 circleciで準備されたimageを利用するのだが、その中でやれ何かをinstallするとか辛いし時間がもったいない。 速さは正義なので、imageをpullしてcodeをmountし、buildするという流れが望ましい。 create docker image まずhugoが稼働するdocker imageをつくる。 世にあるやつがメンテナンスされていないのと、host側の設定をcopyするようなものだったので、動きやすさを含めて自分で作成。 https://hub.docker.com/r/threetreeslight/docker-hugo/ executer type どうするか? executerをdockerで動かしたときに、container内にcheck-outしたfileをどうやってmountするか。 circleciを見る限りvolumeを共有することは困難である。そりゃそうだよね。 https://circleci.com/docs/2.0/executor-types/#using-docker とはいえmachineを使うと Start time が 30-60 sec という。 このリードタイムは許せない。 Remote Docker そこで見つけたのがRemote Dockerという機能 https://circleci.com/docs/2.0/building-docker-images/ To build Docker images for deployment, you must use a special setup_remote_docker key which creates a separate environment for each build for security. This environment is remote, fully-isolated and has been configured to execute Docker commands. ... Read more

April 30, 2018

about

github twitter Qiita slideshare / speakerdeck LTs mastodonがどうやって分散SNSを実現しているのか on shinjukurb#49 at May 24, 2017 jsonapi-resourcesの良い面・悪い面 on shinjukurb #48 at 2016 Data qualityを意識したリファクタリングツール、sicenetist gemについて on shinjukurb #47 at Oct 27, 2016 Dockerizeして
大変だった話、幸せになった話 on TechBlog DeepDive meetup #1 at July 5, 2016 background jobで
気をつけないといかんところ on shinjukurb #37 at May 25, 2016 今だから言えるやらないほうが良かったこと on スタートアップ企業tips共有会 at Apr 27, 2016 AWS Auroraよもやま話 on shinjukurb #33 at Jan 27, 2016 1秒でも早くAutoScale on shinjukurb #32 at Dec 16, 2015 決済って悩むことが多い on shinjukurb #30 at Nov 25, 2015 rails + serverengineで
お手軽daemon on shinjukurb #29 at Sep 30, 2015 what is the best way of method swizzling? ... Read more

April 30, 2018

Don't work hugo autorebuild with dinghy

host側のvolumeをmountしているのだが、その変更をwatcherが補足しない = LiveReloadが動かないのはかなり辛い。 そのため、hugoとdinghyのコードを追う。 そもそもdinghyがmountしたhostのfseventを伝搬できているのか? dinghyは fsevent を vmに伝搬しているはず。 そのため、 inotify-tools を使ってどのようなeventとして伝搬されているのか確認する。 $ docker run -it --rm -v $PWD:/app debian:latest sh % apt-get update && apt-get install -y inotify-tools % cd /app % inotifywait -rme modify,attrib,move,close_write,create,delete,delete_self . Setting up watches. Beware: since -r was given, this may take a while! Watches established. # fileをcontainer内で作成するとcreateのeventを補足する $ docker exec 2a5e08389e9b touch /app/foo.md ./ CREATE foo.md ./ ATTRIB foo.md ./ CLOSE_WRITE,CLOSE foo.md . ... Read more

April 29, 2018

Dockerize hugo on local

blogをtumblerからhugo に移す。 それにともない、まずはlocal開発環境のdockerize。 ちょっとはまったところ そりゃそうだよねってところなのですが dinghy(docker-machine)経由でアクセスするので、assetsの表示を直す hugoの組み込みサーバーはlocalhostをdefaultでbindしている ここらへんはbaseURLとbindを指定することで解決。 # docker-compose.ymlversion:"3"services:blog:build:context:.volumes:-.:/appports:-"1313:1313"command:["hugo","server","--baseURL=http://${DOCKER_HOST_IP}:1313","--bind=0.0.0.0"] watcherが期待通り動いていないので、そこは後日

February 4, 2015

セールスにおけるベストシナリオはエンジニアにおけるワーストシナリオである

(ワーストシナリオっていうのは耐えれる負荷って意味です。) 事業計画を実現に向けてより具体的な計画を立てていくためには、お互いに上記を理解していることが大事だ。 もし、理解していないとビジネスサイドとエンジニアサイドの話し合いは、お互いに猜疑心に満ち溢れていく。実際そうだったし。 例えば ビ「この顧客この時期に取るる予定」 エ「そうすると負荷分散のためにこれとこれをそろそろやろうかな。でも、そうするとこの機能は遅れそう。ちょっと手も回らないから人も増やしてなんとかしたいところだけど」 ビ「うーん、そうしたらちょっとずらそっか?」 エ「えっ?ずらせちゃうもの?」 ビ「現実問題そう簡単には上手くいかないだろうし。掛かるっていうんなら。」 エ「そうしたら、機能開発を先に進めておいたほうがよさそうだね。」 で、あるあるなのは ビ「そういえばこれをここまで進めたいんだけど、いつ頃できるんだっけ?」 エ「ん?話違くない?それをやるんなら人増やしたいし、その動きできてないよ」 ビ「いやいや、遅れるっていうからそれに合わせたんじゃん」 エ「えっ?その必要性がでるまでそれはやらないよ。現実問題がわからないんじゃないの?」 ビジネスサイドはエンジニアに合わせる、エンジニアはビジネスサイドに合わせる。 するとお互いが何も決まらない。だってマイルストーンの決定権をお互いに持っていないのだから。 なぜこのような事態に陥るのか R&Dフェーズや基礎機能を構築していくフェーズは、そもそも物がないので売れないからマイルストーンの決定権は ビジネスサイド < エンジニアサイド でいい。そうでしか動けない。 ただし、売上が立つフェーズ、もしくは積極的に立てるフェーズから ビジネスサイド > エンジニアサイド というマイルストーン決定権の変化が発生する。 言葉にすると ビ「あれ、エンジニアが決めない???しかも毎回言うことが違うの?」 エ「毎回言うこと違うの???っていうかなんでマイルストーンが定まらないの?」 こんな感じ。 解決策としては 見える化して、それを毎週なり振り返ること。今はこれしか思いつかない。 ビジネスサイドは マイルストーンの決定権を持っていることを意識し、現実的な数字を引く。 そして安易にそのマイルストーンをずらす発言はしてはいけない。 エンジニアサイドは ビジネスマイルストーンをビジネスサイドから引き出す努力をする。 マイルストーン達成に向けて必要なことを見える化する。 ビジネスサイドがエンジニアリングが出来る必要が有ると言われる所以はここら辺じゃないだろうか。 ちゃんと見えるかできればそんな努力する必要ないと信じてる。 とはいえ、この解決策が有効か検証し続けるしかない。

September 10, 2014

sshをEC2のタグからpercol経由でよしなにする

掲題の通り辛くなってきたので、雑ですが書きました。 require AWS CLI percol zsh Install AWS Cli http://docs.aws.amazon.com/cli/latest/userguide/installing.html $ sudo pip install awscli Locale周りの設定していなかったのでlocal設定をする $ vim ~/.zshrc export LC_ALL=ja_JP.UTF-8 configure # Configuration $ aws configure AWS Access Key ID: YOUR_AWS_ACCSS_KEY_ID AWS Secret Access Key: YOUR_SECRET_ACCSS_KEY Default region name [us-west-2]: いんすたんすのあるりーじょん Default output format [None]: text ssh-login with ec2 via percol # ec2-ip function ec2-ip() { instances | percol | awk '{ print $1 }' } function instances() { instances=( $(aws ec2 describe-instances \ --query 'Reservations[*]. ... Read more

August 30, 2014

ruby scriptをvimから実行すると、rbenvのrubyが読まれない

require rbenv ruby bash or zsh 問題 ruby scriptをvimから実行すると、rbenvのバージョンのrubyが読まれない 原因 intractive shell起動じゃないから。 解決策 zshの場合は、zshenvに記載 $ vim ~/.zshenv export PATH="$HOME/.rbenv/bin:$PATH" boxenの場合はzshevnにこんな感じ $ vim ~/.zshenv source /opt/boxen/env.sh その他shellの場合 rbenv - Unix shell initialization

August 9, 2014

chefのssl verify warning

man in the middle atack対策として、chef 11.12系からssl verifyが出来るようになった様です。 SSL validation of HTTPS requests is disabled. HTTPS connections are still encrypted, but chef is not able to detect forged replies or man in the middle attacks. To fix this issue add an entry like this to your configuration file: # Verify all HTTPS connections (recommended) ssl_verify_mode :verify_peer # OR, Verify only connections to chef-server verify_api_cert true To check your SSL configuration, or troubleshoot errors, you can use the knife ssl check command like so: ... Read more

August 9, 2014

nodejsのスクリプトをcapistranoでデプロイ

nodeのデプロイ洗ってみたけど、capistranoでやっていたり、shellでやっていたりベストプラクティスなんなんだろーと色々悩んでました。 必須の要件としてはシンプルに2つ。 rollbackできるようにデプロイのバージョニング downtime無しで管理 Require スクリプト本体+http server nodejs coffee-script process管理 pm2 deploy capistrano 下ごしらえ packages $ npm i pm2@latest -g gems $ bundle init $ vim Gemfile source 'https://rubygems.org' gem 'capistrano', '~> 3.2.0' gem 'capistrano-bundler', '~> 1.1.3' gem 'capistrano-npm' $ bundle デプロイ設定 initialize $ cap init cap設定 $ vim Capfile # Load DSL and Setup Up Stages require 'capistrano/setup' # Includes default deployment tasks require 'capistrano/deploy' require 'capistrano/bundler' require 'capistrano/npm' require 'capistrano/console' # Loads custom tasks from `lib/capistrano/tasks' if you have any defined. ... Read more

July 24, 2014

[chef] 複数環境を管理するcookbookをリファクタしてみた

Chefマスターから見たら「えっそんなこともちゃんとやってなかったの?情弱」的な感じかもしれませんが、とりあえず自分で気をつけたポイントをメモしてみました。 ほんとはこう分けた方が良いよ!とかありましたら教えてもらえると嬉しいです! 課題 やっとサービスが成長してきたので、ちゃんとChefで3環境(local, staging, production)を管理しているのですが、 「3rd partyのcookbookも使ってるし、attributeのoverrideをrunlistで行っていて、環境ごとのrunlistに差分が出る。ヤバい。目diff無理」 という素敵な課題が勃発 対策 このrunlist問題に対して、以下のような対策を打って、リファクタしました。 1. バージョンをattribute化してあるものは必ずserver specでテスト これは当たり前ですね。なんでやってなかったんだって怒られそう。 2. site-cookbooks内のcookbookのまとまり感を揃える リファクタ前は、あるpakcageのインストールをcookbook内のrecipeとして管理したり、独立したcookbookとして管理したり、粒度や方針がバラバラでした。 例えば以下のようなものがバラッバラでした。 papertrail monit unicorn そうなると当然、チーム内で新しいpackageを追加したいときに「これって切り出すべき?それともどっかのrecipeにするべき?」って話し合う事が多くなる感じです。 そこで、以下のような大きく4つのcookbookを作って整理した結果、runlistへの見通しも良くなりました。 (分け方は趣味です) initialize 最初にやっておくべき事(sudoとかuserの追加とか、iptablesとか) languages node, ruby, pythonとか db db接続とかdbそのものなど sites nginx周りの設定とかweb server絡み ただ、recipeの内容が複雑になる場合やtemplateを多用する場合は、まとめてしまうとメンテし難くなるのでcookbookとして切り出し、include_recipeするwrap recipeを上記のcookbookに食わせるようにしました。 3. 3rd partyのcookbookを直接runlistから実行せず、包む。 runlistを長くなる原因の一つとして、3rd partyのcookbookをそのままrunlistから実行する事が挙げられると思います。 対策としては、ほぼ2のcookbook切り出した場合と同じで、3rd partyのcookbookをincludeするwarp recipeを作り、attributeもそのcookbook内でまず上書きする方針にしました。 例えばgitの3rdpartyを以下のようにrunlistで記載するのではなく、warpすると以下になるイメージです リファクタ前 // runlist { "environment": "production", "git": { "version: "1.9.0", "url": "https://git-core. ... Read more