タグ

ブックマーク / blog.father.gedow.net (6)

  • Kubernetes、やめました | 外道父の匠

    最近 Kubernetes 全然触ってねーなって思ってたところに、『6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基要らなくない?となった話 – データエンジニアの酩酊日記』を見つけて、自分と異なる立場によるコンテナシステムへの感想を興味深く読ませていただきました。 Kubernetes を推す人がいる一方で、ここには昨夏『Kubernetes、はじめました』と言っておきながら今年に入って全然触らず、ECSを使ったシステムばっか手掛け、Kubernetes いらなくね?って思う人もいるわけで。これはいったいどういうことでしょう、と雑感タイムです。 どうしてコンテナシステムで迷うのか 最初に断っておきたいのは、以下 Kubernetes を否定したり腐すような意図は全くなく、なんでやろ?って自身に問いかけた私見です。やめました、と言ってもウチで今も使っ

    Kubernetes、やめました | 外道父の匠
    hajimepg
    hajimepg 2020/06/04
  • 現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠

    RedHat系におけるRPMパッケージを扱うYUM、Debian系におけるDEBパッケージを扱うAPT、これらはサーバー管理において重要なわけですが、絶妙な度合いで、おざなりに扱ってもわりとなんとか運用出来てしまう感があります。そのため今一度、こんな感じが今風のスタンダードじゃないっすかね(キリッ という構成を説明してみます。 ぶっちゃけ、たいしたことないネタの集合体なので、タイトルに下駄を履かせました。 そもそもパッケージは必要なのか 言うまでもなく必須です。理由は、インストール物のファイル管理が容易になるのと、インストール時間を短縮できるからです。既存のパッケージでconfigureオプションが物足りない時や、RPMパッケージが存在しない場合は作成することになります。 最近はプロビジョニング・ツールによって全て自動化できるので、超簡素なコンパイルのものはレシピに落とし込んで終わりにした

    現代ITインフラの王道をゆくLinuxパッケージ管理の基本構成 | 外道父の匠
  • エンジニアがアウトプットすべき理由 | 外道父の匠

    ブログが流行りだして10年以上が経とうとしているのに今更な内容ですが、エンジニアがブログを書く書かないについて再考する機会があったので、書き留めておきたいと思います。 書く人にとってはメリットがわかってるし、書かない人にとってはデメリットを流せるし、ぶっちゃけ好きにすればいいだけではあるのですが・・・ アウトプットとは ”発信”の方がしっくりくるのでどっちも使いますが、ここでは一般的っぽい”アウトプット”としています。私が思いつくアウトプットとは、 技術ブログを書くこと Wikiに手順やバッドノウハウをまとめること Twitterやコミュニケーションツールで短文メッセージを投稿すること 登壇発表すること 講師やメンターとして育成すること 書籍や連載を執筆すること ソースコードを公開またはプルリクすること で、どれも社内/社外どちらでも問わない、といったところです。ただし、社内におけるコード

    エンジニアがアウトプットすべき理由 | 外道父の匠
  • エンジニアの成長と反抗期 | 外道父の匠

    最近、後進の育成について考える機会があります。 ある時、こんな状況で困ることがあるんだけど、どう思う? と聞かれて飛び出した言葉【反抗期】について考えてみます。 相談内容 育成や生産効率をテーマにした会にて、相談された内容は あるエンジニアが実力以上に過信して自己評価する やたら特定の技術に拘って、結局リリースが伸びたり改悪したりする ・・・んだけど、これは何なんだろう、どうしたらいい?というもの。 これに対し、自身の辿った道も思い直して出した返答が 『それは、エンジニアの反抗期だよ』 もちろんこれは、こどもがヤダヤダ拒否する(=仕事したくない)来の意味ではなく 逆に、やり過ぎによる失敗経路への舵切りのことを指しています。 聞き手はこれで非常に納得がいった様子。 反抗期とは おそらく3~5年目の時期に、技術やアイデアに偏ったものを創り出すことがあります。 そして、閑古鳥/改悪サービスに

    エンジニアの成長と反抗期 | 外道父の匠
  • Fluentd Meetup #2 発表資料 | 外道父の匠

    このブログやTwitterをご縁に、Fluentd meetup in Japan #2 で登壇させていただくことになり、張り切って発表してきました。 発表資料はアニメーションを多様していたのでSlideShareだとわかりづらいかもですが、アップロードしましたので御覧くださいませ。 内容の補足 いくつか質問を受けて答えたりTwitterで見た点について、資料の補足をしておきます。 Agent -> Collector通信経路について Q. なぜVPNにしなかったのか A. VPNは可用性/負荷分散性の点で弱いため。また、VPNサーバや他にもGatewayなど余計な経路を通ることになり無駄である。Agentの増加に対してボトルネックができない構成にしたかったため。政治的な理由で、ある環境だけVPNをはれないといった場合もあり、総合するとGlobal+暗号化 が良い落とし所だった。 圧縮/暗

    Fluentd Meetup #2 発表資料 | 外道父の匠
  • Cloudera Impala発表資料 | 外道父の匠

    11/26 の『Hadoopソースコードリーディング 第13回』でCloudera Impalaの発表をしてきました。 きっかけはTwitter上で、ビールの化身 も◯す の外道父を呼べば?から始まって、1分かからず依頼ツィートが飛んできて引き受けた感じで、Twitterで数分で全てが完結する非常にフットワークの軽い業界になります。 それでは、発表資料や補足などを書いていきます。 リンク Eventbrite : Hadoopソースコードリーディング 第13回 Twitter #hadoopreading togetter : Hadoopソースコードリーディング 第13回 まとめ Inside Impala Coordinator at HSCR 13th – Go ahead! by @repeatedly Inside Impala -Query Exec Engine- by @o

    Cloudera Impala発表資料 | 外道父の匠
  • 1