critical alertのブログ

普段はサーバのお世話係をしています

AWS 認定ソリューションアーキテクト アソシエイトに合格した話

先日 AWS 認定ソリューションアーキテクト アソシエイト を受けてきました。結果は無事に合格することができました!

リザルトはこんな感じでした。

総合評点: 85%

トピックレベルスコアリング:
1.0  Designing highly available, cost-efficient, fault-tolerant, scalable systems: 84%
2.0  Implementation/Deployment: 66%
3.0  Data Security: 90%
4.0  Troubleshooting: 100%

65% 以上で合格という噂があるので余裕を持って合格できたかなと思います。 (模擬試験では総合評点 70% だった)

少し苦手意識があった Data Security が 90% 取れたのでよかったです。

なぜ資格の取得しようと思ったか、どんな勉強をしたかを軽く紹介したいと思います。

続きを読む

我が家の Hue の運用について

おはようございます。 この記事は feedforce Advent Calendar 2017 - Adventar の4日目です。

昨日は 将棋歴17年。成長の止まった僕が、1日20分で強くなる方法。 – Daisuke Mori – Medium でした。

毎日コツコツ練習し、最新の情報をキャッチアップするのは何事にも言えることですね。ちなみに私の将棋知識といえば三月のライオンくらいですね。にわかもいいところです。

さて、先月社内の LT 大会で 「Hue で始めるおうちハック入門」というテーマで LT をしました。 スライドはこちら。

おうちハックガチ勢からすると取るに足らない内容ですが入門としては Hue は手軽で良いですね。

今回は Philips Hue を導入してだいたい一年くらい経ったので現在の運用をまとめておこうかと思います。

続きを読む

Serverlessconf Tokyo 2017 に行ってきました

11/03(金) に開催された Serverlessconf Tokyo 2017 に行ってきました。

参加のモチベーションとしては現在 AWS Batch を活用してバッチシステムを作ろうとしているのと、AWS Lmabda を使って AWS サービス同士をのり付けしているうちにこの分野に興味が湧いてきたところでちょうどいいところに Serverlessconf の開催を知ったため最新情報を仕入れようと思って参加しました。 それからよくある文脈としては「サーバーの管理をしなくていいぜ、やったー」みたいに語られることが多い気がしているので果たして本当にそうか?という疑問を解消したかったのもあります。

イベントそのものの話

飯田橋ベルサールが会場でした。

セッションは2トラックあってどちらも混みすぎることなく基本的に着席して聞けたのでよかったです。 スポンサーブースもアンケートに答えるとTシャツもらえたりして豪華だった気がします。 著名な方が普通にブースにいて気軽に話せるのはよく考えるととてもすごいことなのでは...と思ったりました。

あとお昼に出たお弁当が美味しかった。

以下、聞いてきたセッションの簡単な感想です。

続きを読む

月イチで定期的にもくもく会をやってる話

今年に入ってから月に1回くらいの頻度でもくもく会をやっていて、1月から始めて今月で4回やったのでこの辺で感想をまとめておこうと思います。

もくもく会

d.hatena.ne.jp

どこかに集まって各自で自習をする会、です。

なぜやっているか

自分は普段の勉強や作業は家でやろうとすると誘惑が多すぎてすぐゲームを始めてしまう意志の弱い人間なのでなかなか集中できないタイプだったりします。

以前は他の方が主催するもくもく会に参加していたのですが最近はあまり開催されておらず、かといって家でやろうとしても上記の通り気を抜くと遊んでしまうので最近勉強できてないなと思っていました。

無いなら自分が開催すればいい!ってことで社内で軽く募集したら3人くらい集まったのでとりあえずやってみようということで始まりました。
スタンスは一人でもくもくするのは寂しいのでどうせなら一緒にやる人集まれ〜〜って感じです。

こんな感じでやっている

主催といってもやってることは大したことなくて日時の設定と開催場所の選定くらいです。

基本的には休日の開催で土日どちらか。でもだいたい土曜日です。日程は月末あたりに調整さんを作って日程を決めます。
休日なのは平日の業務後だと力尽きていて別のことをやる気力がないので一日しっかりと時間を取ってやろうという思いです。

時間は 11:00 ~ 19:00 くらいで途中参加、途中離脱OK。 とくに成果の発表とかもしないです。発表したい人はやります!

あとはこのもくもく会専用の Slack team を作って参加者を Invite してます。

やってる場所

意外と大事なのが会場選び。
普通のカフェ等でなくコワーキングスペースの一日利用を活用しています。
一日利用だとだいたい 1500円〜3000円 くらいのところが多いですね。 それで良い環境で作業できるなら安いものです。

コワーキングスペースは安定した Wifi と電源が完備されているというのとまわりの人が仕事なり勉強なりで来ているのでカフェより居心地がいいと自分では思います。(来ている目的がだいたい一緒のためだと思います)

今まで行ったのは下記。それぞれ2回づつ利用。

ここ二ヶ月は LODGE を利用していて、かなり気に入ってます。とにかく広くて綺麗なので居心地がよいです。
周りは普通に会話しているので静かな空間で作業したい人はちょっと厳しいかもしれない。
集中ゾーンのような一人席もあるので一人で行く場合はそれらを活用すると良さそうです。

いまは無料キャンペーン中で料金はかかりませんが有料化されても行きたいですね。

よかったこと

  • 定期的な勉強する時間が作れる
  • 適度な強制力。一人だと気分が乗らなかったりまぁいいかって感じで行かなかったりしてしまうのを防げる
  • すぐそばに人がいてとても気楽に質問とかできる

普段なかなか時間が取れなかったり自宅だと集中できない人などにとてもオススメです。

最近は技術チーム以外の人も参加してくれたりして業務や飲み会以外での交流が持てて個人的には良い会になっていると思います。 何より興味を持って参加してくれるのがうれしい。

さいごに

買ったまま積んでた技術書を読んだり気になってた技術を試したり自由にやってます。(あと久々にBlog書いたり)

もしかすると社外の方と一緒にやったりするといいのかもしれないですが参加者の調整とかあまりその辺を考えたくないのであくまで自分の気軽さを優先しています。 会の運用に悩むようになってしまっては何のためにやっているかわからなくなる気がするので。

そんな感じでこれからも月1回ペースを保ちつつゆるくやっていこうかと思っています。

f:id:critical_alert:20170422185420j:plain

SRE Tech Talks に行ってきました

SRE Tech Talks - connpass

7/25(月)に行われた SRE Tech Talks に行ってきました。

SRE という単語はメルカリさんの有名な記事(下記リンク参照)で初めて知りました。しかし実際にどのようなことを行っているのかあまりピンときていなかったので、具体的な話を聞きたかった。申し込み数がエライことになってましたが運良く当選しましたのでスライドや感想などを簡単にレポートにまとめます。

tech.mercari.com

各セッションタイトルはイベントのページから引用しました。

続きを読む

JAWS-UGおコンテナ支部 #5 に行ってきました

JAWS-UGおコンテナ支部 #5

少し前になりますが6/27(月)に行われたJAWS-UGおコンテナ支部 #5に行ってきました。

コンテナ支部には初参加でした。ちょうど業務でECSを検討しているところで、今回は運用系の話が多そうだったので思わず参加。

みなさんもう普通にコンテナを使っていらっしゃる。具体的な運用例なども聞けたのでかなり参考になりました。

以下メモ付き感想。ちょっとうろ覚えのところもあるかもしれません。目次はイベントのページから引用させていただきました。

続きを読む

rubyのRPMを作るのをDockerとCircleCIにやらせたら便利だった

この記事はフィードフォースエンジニア Advent Calendar 2015 - Adventar4日目です!

みなさんrubyRPMビルドってどうしてますか!

CentOSをメインで使っていると最新のrubyyumで入らないのでどこかのリポジトリからインストールするか自前でビルドする必要があるかと思います。

プロビジョニングのタイミングでrbenvやmakeで入れてもいいのですがciや新規ホストを立てた時など毎回rubyのビルドをするので時間がかかってしまうんですよね。 それが嫌でrubyはリリースされるたびにrpm化してインストールするようにしています。 ところがrpmのビルド環境って用意するのが面倒だったりビルドしたい環境ごとにvagrantを立ち上げて〜とか意外と手間がかかる。

自動化したいなーと思っていて、Dockerは特定の環境を再現するのに最適だし、CircleCIはGitHubのpushやmergeをトリガーにしてあれこれできるし、これだ!っていうことでDockerとCircleCIを使って自動でビルドできるようにしました。

今回の記事で使ったソースコードはこちらです。

critical-alert/oreno-ruby-rpm · GitHub

全体の流れ

circle.ymlを見るとなんとなくわかると思いますが、流れとしては以下のような感じ。

  1. GitHubにpushまたはマージされたタイミングでCircleCIが走る
  2. docker build でdocker imageをビルドする
  3. docker run で実際にRPMビルドを行う
  4. docker cp でコンテナの中から出来たRPMを取り出す

RPMを取り出すと書いていますがこれは正確ではなく、$CIRCLE_ARTIFACTS というパスにファイルを置くとCircleCiのArtifactsからDLできるようになっています。

ポイント

実際にRPMのビルドを行っているのはdocker runで立ち上げたコンテナの中です。 肝心のDockerfileはこのようになっています。

FROM centos:6.6
MAINTAINER hirokazu SUGIUCHI

# setup
RUN yum update -y
RUN yum install -y rpm-build tar

# ruby depends
RUN yum -y install readline-devel ncurses-devel gdbm-devel glibc-devel gcc openssl-devel libyaml-devel libffi-devel zlib-devel

# builduser
RUN useradd rpmbuilder

# build prepare
RUN mkdir -p /home/rpmbuilder/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
RUN chown rpmbuilder:rpmbuilder /home/rpmbuilder/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
WORKDIR /home/rpmbuilder/rpmbuild
ADD http://cache.ruby-lang.org/pub/ruby/2.2/ruby-2.2.3.tar.gz SOURCES/
COPY ruby22x.spec SPECS/ruby22x.spec
RUN chmod 777 /home/rpmbuilder/rpmbuild/SOURCES/*

# build
USER rpmbuilder
CMD ["rpmbuild", "-ba", "/home/rpmbuilder/rpmbuild/SPECS/ruby22x.spec"]

いくつかポイントがるのでそれぞれ解説します。

rpmをbuildするuserを作った

通常Dockerはすべてrootユーザーでコマンドが実行されますが、rpmをビルドするときはrootでのビルドは推奨されません。(今回に限ればそれほど問題は無いと思いますが) お作法に則ってrpmbuilderという一般ユーザーを作成しています。

Dockerfile内でUSERと指定すると、それ以降はその指定されたユーザーでコマンドが実行されます。 それより前でパーミッションの調整しているのはそのためです。

最後にCMDでrpmbuild

初期の段階では build.sh なるものを作ってそのなかでrubyのソースをダウンロードし、rpmbuildコマンドを実行する、としていました。 そのあとdocker run時に docker run ruby-rpm /bin/sh ./build.sh といったようにshスクリプトを実行させていました。

run時にスクリプトを叩くのはあるあるですが、そのようにしてしまうとそのスクリプトの中であれこれやってしまい何をやっているのかわかりづらくなるのと、スクリプト のメンテも必要になってしまうのでDockerfileで完結するならその方が良いと考えDockerfileのみで完結するようにしました。

Dockerfileの中にCMDがあることによってそのコンテナの役割が明確になるというメリットもあります。 そうすることで、このコンテナはrpmを作るバイナリとして扱えるようになったとも言えます。 (docker imageをrunするだけでrpmがポンとできるような...)

課題

複数のOSに対応していない。今回はCentOS6でビルドしましたが、CentOS7にも対応したいです。 これはDockerfileがDockerfileという名前ではなくてもよくなったことを利用してDockerfileを複数(Dockerfile_centos6Dockerfile_centos7)作り、docker build時に指定しそれぞれ実行すれば作れそうです。

まとめ

  • 特定の環境で実行する処理をDockerで行った
  • GitHubとCircleCIを使うことによって誰でもRPMを作れるようになった
  • Dockerfileを知るいい機会になった

これでrpmのspecファイルとrubyのソースURLをちょいっと変更してpushすればrubyrpmが出来上がります。 12/25日にはrubyの2.3.0が公開されるはずなのでその時には活躍してもらおうと思っています!

というわけで、5日目の明日はフィードフォースのMaker、kasei_sanです!

参考リンク

大変参考にさせていただきました