re:annkara

Web技術を中心に学んだことを書き溜めていきたい。

Japan Container Days v18.04に行ってきました。

Japan Container Days v18.04に参加してきました。

containerdays.jp

チケットが事前に完売していたり、当日の盛況具合からコンテナやKubernetesなどの技術への注目度がますます増してきたのだなと実感しました。
以下、自分が聞いたセッションの振り返りです。

スライドのまとめはこちらの記事でまとめてくださっています。

medium.com

サイバーエージェントにおけるプライベートコンテナ基盤AKEを支える技術

AKEというサイバーエージェント社で独自に実装しているコンテナ基盤の紹介をしていた。
自社で独自のコンテナ基盤を実装するという発想がそもそもなかった自分は純粋に凄いなと思ったし、Kubernetesなどの内部実装を知ることで、自分の好きな通りにプラットフォームを構築できるというのは楽しそうだとも思った。
Kubernetesを利用するだけではなくて、内部動作を深く学んでいこうと思えた。

マイクロサービスアプリケーションとしての機械学習

mercari社の機械学習を利用したサービスの展開とその運用についてのセッションだった。
私自身、機械学習についてはほとんど知らなかったのだけど、スライドに記載ある通り
mercari社での機械学習システムに求められるシステム要件が非常にハイレベルなものであり、かつ、それを1週間ほどで準備するSREの技量の高さに非常に驚きを覚えました。
また、機械学習を利用したサービスの運用は、Webサービスの運用とは異なった側面を持つというのは自分にとっては新しい発見で、そのサービスにあった運用を考えなければならないのだと考えさせられました。

"Yahoo! JAPANのKubernetes-as-a-Service"で加速するアプリケーション開発

KaaS(Kubernetes-as-a-Service)について話していたのが特に記憶になっている。
Kubernetesを利用することで、コンテナ化されたサービスの運用にはメリットが生じるが、Kubernetes自体の運用が新しく発生してしまう。
これはKubernetesだけに限った話ではないと思っていて、現状の課題を解決するために新しいツールを導入したら、そのツール自体の運用が発生するというのはよくある話だと思っている。
そこでKubernetesの拡張機能を利用して、Kubernetes-as-a-Serviceを実装したとのこと。
ここでもKubernetesの内部実装や機能をよく知ることで、自分たちのソリューションを実装するという話が出てきて、尚更Kubernetesについてよく知りたいと思った。

Cloud Native Apps入門

CNCFではCluod Nativeなアプリケーションは以下の3つの要素を備えていると明記している。

Charter - Cloud Native Computing Foundation

  1. Container packaged.
  2. Dynamically managed.
  3. Micro-services oriented.

また、Cloud application maturityといったものもあったりする。

www.nirmata.com

GitLabやGitHubの事例も紹介されていたので、アーキテクチャの部分とかあとでちゃんと見てみたいと思う。

Spinnakerを利用したKubernetesへの継続的デリバリ

Spinnakerの紹介セッションだった。
コンテナ環境のCI/CD周りって、デファクトが確立されていない分野っていうのは感じている。
CI/CDツールの選定や、Kubernetesを利用するのであればYAMLの管理やデプロイ方法、HELMを利用するかなどいろいろ考えなきゃいけない。

Kubernetesの運用設計ガイド

スライド上がったら別途まとめたい。
Kubernetesの設計思想を踏まえた上での運用設計であったり、自律的な組織を目指すといった部分は非常に共感できた。
運用設計の具体的な部分については、ベストプラクティスと被るところが多かった気がする。

kubernetes.io

medium.com

『コンテナ疲れ』と戦う、k8s・PaaS・Serverlessの活用法!

DockerやKubernetesだけじゃなくて、PasSやServerlessも視野に入れながら適切な技術を選択するのが大事だよねっていうセッションだった。
DockerやKubernetesを導入することで、アプリケーションの実行や管理っていう側面はある程度楽になったかもしれないけど、その分知らなければいけない領域が増えたり、別途オペレーションが必要になったりと、意外とやることだったり気にしなきゃいけないところだったりが増えているのも確かだと思う。

Fluentd and Distributed Logging in Container Era

@repeatedlyさんのセッション。
セッションが20分だったからなのか、めっちゃ早口だった。
隣の人が今日一何を言っているかわからないと言っていたのが印象的だったが、コンテナ環境のロギング周りのこと知っていないとついていけないなとは感じた。

同名のタイトルでTreasure Data社のブログがあるのでそっち見てみても良いかも。

blog.treasuredata.com

全体的に参加人数とキャパが見合ってなかった気がするけど、最高のカンファレンスでした。
運営の方やスピーカーの方には感謝しかありません。
また12月にもあるみたいなので、そちらも是非参加したいと思います。

「あなたは何をしている人なんですか?」という問いに対して

カイゼン・ジャーニーを読み始めた。

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

表題の問いは、本書の第一話で主人公に対して投げられた問いであり、主人公はこの問いに対して何も答えることができなかった。

この問いに答えられるということは私自身、非常に重要だと考えている。
なぜなら、自分の中の一番大事な軸や信念といったものがあなたの中には存在するか、という問いだと考えるからだ。

昔の私ならこの問いに答えることはできなかったと思う。
ただ、今まで経験したことを振り返り、改めて今していることを考えてみると答えられる気はする。
なので、自分自身のためにもこの問いに答えてみたいと思う。

私は何をしてきたか

最初の3年間はCOBOLを使って、メインフレーム上で稼働する業務アプリケーションやバッチプログラムの新規開発や保守業務を行っていた。
元々はWeb開発がやりたいと思っていたのだけど、自分の性格上(明るいとかそんな感じ)その業務に一番適しているとのことで配属が決まったらしい。

配属されてしまってからは仕方なしに、Excel仕様書をもとにコーディングし、手動でコンパイル、リンク、デプロイ(というかライブラリに配置)し、JCLでバッチを実行、または端末から手動でテスト打鍵を実施するといったことをしていた。
自分がエンジニアとして夢見ていたような仕事ではなくて、非常に泥臭いことを愚直にやっているものだなぁと感じていたと思う。

2年目くらいからは新しく構築されるWebシステムの一サブシステム(メインフレーム側のバッチ処理)の設計からやるようになって、本番リリース後の保守までほとんど自分一人で行うようになっていた。
新しく何かを作るという行為は非常に楽しかったが、同時に自分の作ったものが本番で正しく動くのかという不安の方が大きかった気がする。
特に難しい処理でもなかった気がするけど、データの源泉が外部サービスで、しかもそのサービスの仕様書を見てもどのタイミングでデータが提供されるかといったことが明確に記載されていなかったからだ。しかもお金周りの処理だったので尚更不安だった。
本稼働直後、特段大きな障害はなかったのだけど、データの整合性(データが提供されない)が取れなかったりでエラーがちょくちょく発生していたのを覚えている。
その度にエラーに対処したり、プログラムを修正したりしていた。
この時の経験から、外部サービスとの連携部分は非常にナイーブで仕様をちゃんと把握しなければならなかったり、仮にエラーが発生しても気づけるような仕組みやエラー処理の重要性に気づいた気がする。

3年目は業務のど真ん中を司る、由緒正しきCOBOLプログラムと相対することとなった。
この機能で障害を起こしてしまったら、一発で金融庁報告となるようなプログラムである。
そのくせ私はその業務に関して全くの門外漢であり、かつ度重なる本番リリースで過度に肥大してしまったプログラムを相手にしなければならず、プレッシャーは半端ないものだったと記憶している。
私の経験不足に関して周りの方も理解しており、元々担当していた方の協力を得られたり、私の上に別の先輩を配置してくれたり、経験豊富な協力会社さんを割り当ててくれたり、私の経験不足を補ってくれるような人員配置をしてくれたことが唯一の救いだった。ただ、本番リリースの数カ月前に直属の先輩が退職してしまったが...
由緒正しきプログラムに関しては、プログラムの規模に対して適切に機能分割されていたため、業務を適切に理解し、仕様を把握し、大量のExcel仕様書に反映される作業とそれをコーディングすることを除けば、今思うとそこまで大変ではなかった...そんなわけない。
業務を適切に理解するための必要な知識が私には致命的に欠けていたし、そこが一番重要な部分だったと思う。
その点を補うために元の担当者に設計部分を担ってもらい、実装・テストは自分たちで担当するという適切な役割分担を行えたこと。 そして、徹底した現新比較テストと新機能部分の単体・結合・システムテストを実施をすることで、自信を持って本番リリースを迎えることができたと思う。
この時の経験からは、適切な役割分担やどのようにして品質を担保するかといったことに妥協しないことが重要だと学んだ。
私が持っていない知識を身につけることも重要だが、その知識を持っている人と協業して物事を成していくこと、単体・結合・システムテストと順を追ってテストをしていくことで、早期にシステムの欠陥を把握して、修正するというサイクルを回せるのだとも学んだ。

そして一番の気付きは、私はこのまま一生この仕事をしていくことはできないということだった。
決まった開発ツール、決まった開発プロセス、秘伝のタレと化した膨大なCOBOLプログラム、大量のExcel仕様書、求められるのは業務知識や協力会社さんのマネジメント...
こういったものを私は否定するつもりは毛頭ないし、今あるシステムのお陰で業務が成立しているというのも理解している。
ただ、私がこのような仕事を一生続けていきたいか、自分が思い描いていたエンジニア像は果たしてこれだったのかというとそれは違っていた。
Twitter上ではエンジニアたちが楽しそうに技術の話をし、ブログ上では素晴らしいアウトプットをしている人たちがたくさんいた。私もどうにかしてそちらに行きたかった。

このリリースが終わる頃には、退社しようと考えていた。自分の経験はメインフレーム上でのCOBOL開発しかないし、独学でJavaなりHTTPなどの学習はしていたものの、実際に何かを作ったりしていたわけではないので、アピールできるものが何もなかった。GitHubやブログのアカウントは持っていたが、草も生えない状態だった (それは今も一緒だが...)。
なので、次の会社が決まらなくても退社して、技術を磨こうと考えていた。結果として、社内の別の部署に異動することとなるが、それは今思うと良かったのだと思う。 当時の私は、どうにかして今の職場を離れたいという気持ちが強く、自分が何をしたいのかということがはっきりとしていなかったのだ。
恐らく、この時に「あなたは何をしている人なんですか?何がしたい人なんですか?」と聞かれても何も答えられなかったと思う。答えられたとしても明確な何かを伝えられなかったと思う。

私は何をしているか

そんなこんなで、入社して4年目で今いる部署に異動してきた。
今いる部署はWebアプリケーションの開発と運用の間にいるような部署で、内製フレームワーク(良いかどうか置いといて)や社内ライブラリの整備、開発者ツール(EclipseMaven、npm、Vagrant等々)の提供や、CI/CD周りの環境整備を行っている部署である。
最近だとJIRAやBitBucketなどのツールを導入し、タスク管理や構成管理の改善を図っていたりする。
時にはWebアプリケーションのパフォーマンスやシステムのキャパシティの課題に対して、開発・運用と協調して解決にあたったり、アプリケーションの障害時には障害解析や解決策の立案なども行ったりする。

今の部署に異動してから、技術に対して誠実に向き合うという気持ちが一層強くなった。
入社してから知識を得ることを疎かにしてきたつもりはないが、それがちゃんと身についているか、業務に活かすことができるか、何かの問題解決に繋げられるかといった点で学んできたとは言いがたかった。何かを知るという意味で知識の幅を広げることはできたが、それを深く掘っていくということができていなかったのだと思う。これは今後の自分の課題だと認識している。

今年で入社して6年目、今の部署に来て3年目となる。
開発と運用の間にいることで、開発や運用の大変な部分や課題を客観的に見ることができるようになったと思う。それと同時に、チームの課題も見えるようになってきた。それは前のチームとも一緒だったのだけど、役割が分担されていて、その領域の知識が人依存になり過ぎている点だ。
知識や経験を何かしらの形で共有することで、チームとしてレベルアップできるのではないかと思っている。
なので自分一人でできることとして、障害が起こった際には、振り返りの資料を作成し、チームで共有するということをしている。
まだ目に見えた成果は上がってないけど、続けていきたいと考えている。

改めて振り返って、私は何がしたいのか

COBOLメインフレームといったいわゆる枯れた技術に嫌気がさしたわけではなくて、改善できる余地を残しつつも目の前の業務に追われて今までと同じやり方で仕事をするということに慣れきった人間になりたくないと強く思っていたのだと思う。
そして何より私はインターネットというものが好きで、インターネットを支える技術というものにすごく惹かれているのだと思う。それが今の仕事をしているうちに、Webアプリケーションを開発する人や運用する人を支えることも含めて、今いる場所をもっと良くしていきたいのだと思う。自分が知っていることを増やしていき、今いる場所、今ある開発プロセス、今ある運用プロセス、今あるシステム、これから作られていくシステム、こういったものをより良くしていくことが私がやりたいことなのだと思う。その為に私は学習し、今いる場所で応用していくのだろう。

「あなたは何をしている人なんですか?」という問いに対して

最初の問いに戻る。 「私は何をしている人なのか?」 私はきっとこう答えるのだろう。
「自分の知っていること、チームの知っていることを増やすことで、今いる場所をより良い場所にしていくことをしています」と。

「本を読む本」読書メモ

最近、本を読んでいても漠然と読んでいるだけで、何も身についていないと思うことが非常に多いので、本を読む本 (講談社学術文庫)を読み返している。

本書では読書には4段階のレベルがあるという。

  1. 初級読書
  2. 点検読書
  3. 分析読書
  4. シントピカル読書

初級読書については、基本的な読み書きができれば良いとのことなので、主に点検読書についてまとめておく。 分析読書、シントピカル読書については本書をまだ読みきれていないので、また機会があればまとめておきたい。

点検読書

点検読書には2つの段階があり、それは拾い読みと表面読みである。
点検読書を通じて読み手は以下の問いに答えられなければならない。

  1. その本は何について書いたものであるか
  2. その本はどのように構成されているか

勝手に尊敬しているid:y_uukiさんは、この段階で「この本を読んで達成したいことは何か」という問いも追加されており、この点は真似したいと思った。

全体把握というのは、書籍「本を読む本」でいうところの読書の第2段階「点検読書」のうち組織的拾い読みに該当する。さらに同著には、積極的読書のためには質問をすることが重要と書かれており、点検読書の段階では、「全体として何に関する本か」、「何がどのように詳しく述べられているか」に関する質問に答えるとよい。自分の考えでは、「この本を読んで達成したいことは何か」という質問にも、点検読書の間に答えられるとよいと思っている。

書籍「詳解システム・パフォーマンス」 下読み - ゆううきメモ
拾い読み

これから読もうとする本が、本当に読むに値するか判断するための読書方法。以下の段階を経て判断する。
これらの段階を経て、上記に述べたような問いに答えていく。

  1. 表題や序文を読む
  2. 本の構造を知るために目次を調べる
  3. 索引を調べる
  4. カバーに書いてある謳い文句を読む
  5. 議論の要と思われる部分を読む
  6. ところどころ拾い読みする
表面読み

とにかく通読してみる読書方法。
理解できない部分や、知らない単語、脚注などは一切無視してとりあえず読み進めてみる方法。

点検読書を行うことでその本の全体像を掴むことができる。
また、「本を読んだ後に何を達成したいのか」という問いを立てることで、自分が身に着けたいことを明確にすることができる。

「本を読む本」を点検読書する

点検読書についてまとめたので、本書を点検読書してみる。

何について書かれたものか

読書の方法論について書かれた書籍である。
読書をする際に自ら問いを立て、知識を得て、思考し、自分の立てた問いに答えられるようになることで内容を自らのものにしていく方法論について書かれている。

どのような構成になっているか

第一部で読書に必要な姿勢(自ら問いを立て、答える)と読書の段階について述べ、第二部、第三部、第四部では各読書の段階における方法論について述べている。

達成したいことは何か

読後に何を身につけることができたか、明確に述べられるように読書の方法を身につけたい。
そういう意味では、点検読書の方法論を知り、次に読む本の読み方を身につけられたのではないかと思う。

本を読む本 (講談社学術文庫)

2017年の振り返りと2018年の目標

2017年の振り返り

とある業務アプリケーションのパフォーマンステストと、タスク管理ツールであるJIRAの運用ばかりやっていた気がする。

パフォーマンステスト

普段扱っているシステム規模はユーザ数で見ると多くとも5,000ユーザくらいの規模だったのだけど、その10倍のユーザ数が見込まれるシステムを構築するということで、パフォーマンステストの期間を十分にとって検証するということを半年くらいやっていた。

主にスループット(単位時間あたりのトランザクション処理件数)やキャパシティ(高負荷時のCPU使用率、メモリ使用率、ディスク容量)などを検証のポイントとして、スクリプトを作成し、実行、検証などを行っていた。

パフォーマンステストにおいて大事なことは、システム全体の構成を把握し、適切な箇所を適切な方法でモニタリングするということが非常に重要だと学んだ。 実際、サービスイン後モニタリングしていた部分においては障害は発生しなかったものの、モニタリングしていなかった部分が原因で障害が発生してしまった。モニタリングや監視をしていない部分については、障害が発生しても運用側からは検知することができないことを経験し、改めてモニタリング・監視の重要性を学んだ。

また、パフォーマンステストについて組織内に体系だった知見がまとめられていないため、自分が主担当として実施する際に効率よくテストを行えなかった気もする。その辺の体系化をしようしようと思いつつも年があけてしまったので、今年の目標の1つとしてまとめていきたいなと思う。

JIRA

JIRAの管理者をやっているので、設定周りにはだいぶ強くなった気がする。
ただ、実際の現場に導入しようとすると、今までのやり方(Excelによる管理)からだいぶ変わってしまうことだったり、ExcelでできたことがJIRAではできなくなってしまうことから現場からの反発はだいぶ受けてしまった。
JIRAだけに限らずこういったツールを導入する際にはまず、ツールを利用する以前のあるべき姿を定義し、それを実際の利用者と共有するということが非常に重要なことだと実感した。
極々当たり前のことだけど、実際の利用者からのヒアリングと課題の共有、そしてそれに見合った解決策を考えていくというのが非常に重要なのだと実感した。

プログラミング

メインフレームとの通信を行うインターフェースライブラリの実装や、JIRAのREST APIを叩くクライアントライブラリの開発などをしていたものの、プライベートではほとんどプログラミングしていなかった。
テスト駆動開発のxUnitをJavaで再実装したりはしたものの、実際に何か学んだかと言われると何も身についていないので、ほとんど意味がなかったと思う。

2017年まとめ

インフラエンジニアではないものの、システムの運用に携わることが多かった一年だった。
振り返ってみると自分はアプリケーション開発(エンドユーザーに利用してもらう実サービスの実装という意味で)でもインフラ(物理的なサーバ、ネットワークを取り扱う領域という意味で)でもなくその中間層を扱うことが好きなのかもしれないと感じている。
この中間層というのがSREやウェブオペレーションエンジニアリングといった分野だとは感じているものの、自分のなかでまだ整理ができていない。
ただ、自分が進みたいと思う大きな方向性というのは得られたと思うので、今までに比べると実りある1年だったと思う。

2018年の目標

今年で30を迎えるので、今一度自分の人生というものを考えていきたい。

人生について

今まで自分の人生というものを真面目に考えてこなかったと思う。
受験や就職活動といった人生のイベント事においては、その都度目の前の目標をクリアすることばかり考えていたけど、どういった人生を送りたいのかということを真面目に考えたことはなかったと思う。
自分がいつ死ぬかなんてわからないけど、少なくとも直近3年間をどのように生きていきたいかくらいは真面目に考えたい。

エンジニアとして

Webシステムの信頼性を向上させるためのエンジニアリングを身につけていきたい。
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチームウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE)といった書籍を中心に、Linux、Web・DB、HTTP、TCP/IP、CD/CI、監視、モニタリング、MSA、プログラミングといったキーワードを今一度学び直していきたい。
また、学んだことや考えたことを適切に言葉として表現する力も身につけていきたい。何かを思考するということは好きなのだけど、人に伝えるという行為が非常に苦手なので。
プログラミングに関しては、それ自体を目標とするのではなく、何かを実現・解決するための実装をすることを目標としたい。個人プロダクトを実装することができれば良い。

健康面

社会人になってからというものの、体重が右肩上がりなので痩せたい。現状、67kgなのでせめて63kgくらいまでは落としたい。
単純に飲み過ぎだと思うので、節制したい。

金銭面

貯蓄はしてるものの、収入が会社からの給料だけなのも不安なので、複数の収入源を得たいと思う。
今流行っている仮想通貨でもいいし、株でもなんでも良いので。

2018年まとめ

30という節目を迎えるにあたり、ちゃんと自分の人生というものを生きていきたい。
それはなんとなく生きていくのではなくて、自分でしっかりと考えて行動するということだと考えている。
そのためにも日々振り返ってみて、都度ブログにまとめていきたいと思う。

Dockerメモ

職場でもいよいよDockerの導入が検討され始めたので、本腰入れて学習していくかと思い積読となっていたオライリーのDockerを読みました。

Dockerコマンド周りやDocekrfileの記述方法など、細かいところをまとめていくのはしんどいのでDocker周りの技術を中心にまとめていこうと思います。
Dockerをローカル開発環境だけでなく、オンプレ上の開発環境、本番環境に適用して行く際に、導入・運用に必要となるであろう技術スタックを俯瞰できるようにしておきたいというのがメモの目的なので。

あくまで書籍ベースなので、情報が古い場合もあるのでご注意を。

Dockerのアーキテクチャ

Dockerデーモン

コンテナの生成、実行、モニタリングとともに、イメージの構築と保存を担う。 常駐プロセスとしてサーバなどで稼働しており、Dockerクライアントからのリクエストを受け付ける。

Dockerクライアント

HTTP経由でDockerデーモンに通信するために利用される。
dockerコマンドがクライアントに相当するものだと思うのだけど、HTTPが話せればよいということなので、クライアントライブラリ経由でも可能らしい。
今の所あまり理解できていない気がする。

Dockerレジストリ

イメージの保存と配布を担う。
デフォルトのレジストリはDocker Hubで、ローカルに存在しなければDocker Hubに探しに行く。
もちろん独自のDockerレジストリを立てることも可能。

Dockerの周辺技術

Docker単体のみでサービスを構成することは難しいため、それを補う技術がある。
Dockerが提供するものもあれば、サードパーティ製のものもあり、ユーザはそれを取捨選択することができる。

Dockerが提供するものは以下の通り。

Swarm

Dockerのクラスタリングツール。
Dockerホストが複数立ち上がっている場合、統合して扱うことができる。

Compose

Swarmが分散されたDockerホストを統合するツールであれば、Composeは同一ホスト上で稼働する関連したDockerコンテナ群を統合するためのツール。
docker-compose.ymlファイルに各コンテナの設定を記述することで、複数コンテナの起動や停止を管理できる。

Machine

Dockerホストをローカル、またはリモート上に構築するためのツール。

Kitematic

Mac OS及びWindows向けのDockerコンテナを管理するためのGUIツール。

Docker Trusted Resistry

オンプレミス上でレジストリを構築するためのサービス。
他にもパッケージ経由でインストールできる、Docker Resistryもある。

他にもサードパーティ製のサービスは以下のように大きく分類できる。
ここでは列挙にとどめておく。詳しいことは各分野毎のツールを実際に試してみて、また別の記事としてまとめておきたい。

ネットワーキング
  • Weave
  • Project Calico
サービスディスカバリ
  • etcd
  • SkyDNS
  • Consul
クラスタリング及びオーケストレーション
  • Kubernates
  • Mesos
  • Fleet
コンテナ管理
  • Rancher
  • Clocker
  • Tutum

感想

Docker自体が発展途上の技術であり、それを取り巻く環境も変化が激しい分野だと思います。
他の技術同様、利用することを目的にしてしまうと変化に追いつくだけで疲れてしまうと思うので、Dockerはどんな技術で何を解決するものなのか、
そして自社の環境にどのような形で適用していくことができるのかということを念頭に置かないといけないなと思いました。
そういった意味では今回、そもそもDockerとは、コンテナ技術とは、など基本的なところをまとめていないのでまとめていきたいと思います。

ただコンテナ技術としてのDockerを考えると、アプリケーションとその依存関係をイメージとして固め、docker runすれば簡単にアプリケーションが起動できるという仕組みは非常に便利だとも思います。
要は使い方さえ間違わなければ便利なツールであると。
どうやって利用していくのかという点も引き続き考えていきたいと思います。

docker + fluentdでハマった話

データ分析基盤構築入門を購入していたので、読み進めようと思ったら環境構築でハマったのでメモしておく。

書籍上では、dockerがインストールされていれば、GitHub - efkbook/blog-sample: a kind of blog implementation written in Go integrated with fluentd and Elasticsearchここからクローンして、docker-compose up で各コンテナ群が立ち上がるとのことだったが、fluentdのコンテナが何故か立ち上がらなかった。

とりあえず対症療法的に、以下のようにDockerfile-fluentを書き換え、コンテナとイメージを削除したら起動するようになった。

FROM fluent/fluentd:v0.12-debian  
RUN ["gem", "install", "fluent-plugin-elasticsearch", "--no-rdoc", "--no-ri", "--version", "1.9.2"]  
RUN ["gem", "install", "fluent-plugin-record-reformer", "--no-rdoc", "--no-ri", "--version", "0.9.1"]  

とりあえずのメモということで。

今年の目標

Javaを中心に継続的にプログラミングしていく(RustとかOCamlとかも触れればよし)
Linux周りの知識もつけていく
③自分プロダクトを作っていく
④今年も一年健康であること