サーバエンジニアが「開発力」を持つ意味 - Gosuke Miyashita
初出: Software Design 2009年4月号（2009年3月18日発売） 宮下 剛輔 サーバエンジニアの定義 本特集では、サーバエンジニアが開発力を持つことにより、どのような力を得ることができるのか、日々の業務にどのように役立てることができるのか、具体例とともに紹介します。 本題に入る前にまずはここでのサーバエンジニアの定義を明確にし、特集全体のコンセプトについて説明します。 クライアント/サーバ型のシステムを考える場合、サーバ側は大まかに以下のようなレイヤーに区分できます。 アプリケーションレイヤー ミドルウェアレイヤー OSレイヤー ネットワークレイヤー これらのレイヤーのうち、ミドルウェアレイヤーとOSレイヤーを主担当とするエンジニアを、本特集記事でのサーバエンジニアと定義し、対象読者と想定します。その中でも特に、オープンソースソフトウェア（OSS）をメインで扱うエンジニ
フリーランスになって6年が経った - Gosuke Miyashita
会社勤めしていないと、評価制度というものがなく、自分がやったことをまとめる機会もないので、今年も軽くまとめエントリを書いておく。 フリーランス情報、表に色々出てくるのはとても良いんだけど、本当に人によって様々なので、色々な情報見比べた方が良い、と思ったので、リンク集的なものをつくってる。 https://t.co/GJ0HdI4LEC — Gosuke Miyashita (mizzy) (@gosukenator) June 6, 2019 放置してアップデートしてないなこれ… 仕事について 昨年の振り返りエントリ からの変更点としては、トレタ さんとは契約終了となった。2年間ありがとうございました。 リクルートマーケティングパートナーズ さん、タレンティオ さん、アカツキ さん、某社さん、さくらインターネット研究所 さん、の5社の仕事は現在も継続中。 「某社」さん、昨年の時点では名前を
フリーランスになって4年が経った - Gosuke Miyashita
フリーランスとして食っていけなくなったのでアルバイト始めました pic.twitter.com/AG92ed5xsI — Gosuke Miyashita (mizzy) (@gosukenator) March 23, 2018 このツイートは、たまたまセブンイレブンの制服を着る機会があったので着てみたついでに撮影して冗談でツイートしただけ。ツイートした後に、あ、これエイプリルフールネタにとっておけば良かった、と思った。 仕事について 昨年も一昨年と同様、リクルートテクノロジーズ ATL での仕事がメインで、それ以外には golang でミドルウェアを実装する仕事や技術顧問的な仕事が少し、という感じだった。 ATL の仕事としては、libspecinfra の開発をしていたけど、昨年いっぱいで契約が終了した。libspecinfra の開発は続けたいと思いつつも、仕事として時間が割けなく
MHA for MySQL の概要 - Gosuke Miyashita
MHA for MySQL の導入を検討していて、まずは社内の技術者向けに、MHA for MySQL の概要を伝えようと、主に オフィシャルなドキュメント からポイントを抜粋して社内向けの Wiki に書いてみた。本当なら、オフィシャルドキュメント全体に目を通してもらうのがいいんだけど、英語なので、はじめの一歩としては敷居が高く感じる人もいるだろう、ということで。 特に外に出してまずい情報があるわけでもないので、このブログでも曝しておきます。 MHA の概要 MySQL エキスパートとして世界的にも著名な松信嘉範氏による、MySQL マスターの HA 化を行うためのツール。Perl 製。 最小限のダウンタイムで、データの不整合を防ぎつつ、マスターのフェイルオーバーを行う、というのが主な機能。 また、既に動作している MySQL に影響を与えることなく導入できる。 機能は大きくわけると以下
puppet の通信の仕組みにちょっと立ち入ってみる - Gosuke Miyashita
puppet のクライアント/サーバ間通信は https + XMLRPC で、認証は SSLv3 の証明書認証が利用されています。 通常、SSLv3 で証明書認証とかいうと、CA とか、自己署名証明書とか、色々めんどくさかったりしますが、puppet はこの辺りはほとんど自動で処理してくれるので、とても楽です。 例えば、puppet サーバ側では、puppetmasterd をはじめて起動した時に、CA 関連ファイルや自己署名証明書などを、/etc/puppet/ssl 以下に勝手に作ってくれます。 $ ls -R /etc/puppet/ssl /etc/puppet/ssl: ca/ certs/ csr_kenny.southpark.pem private/ private_keys/ public_keys/ /etc/puppet/ssl/ca: ca_crl.pem ca_
Infrastructure as Code 再考 - Gosuke Miyashita
Infrastructure as Code という言葉が現れてから少なくとも8年ほど経過しており、この言葉もすっかり定着したように見えるが、Martin Fowler 氏が最近自身のブログで Infrastructure as Code について触れており 、また、氏の同僚である Kief Morris 氏が O'Reilly Media から Infrastructure as Code という本を出す（現在 Early Relase 版や Free Chapters が入手できる）ようなので、このタイミングで改めて Infrastructure as Code について、その歴史を振り返るとともに、現在の状況について整理してみようと思い、このエントリを書くことにした。 内容的には、以前書いた インフラ系技術の流れ と若干重複してる部分もある。 そういえば日本でも最近、サーバ/インフラ
インフラ系技術の流れ - Gosuke Miyashita
ここ最近のインフラ系技術の流れがおもしろいなー、と思ったので、Puppet が出た辺りぐらいから、振り返って整理してみる。殴り書きなので、後から修正したり書き加えたりするかも。特に後半の方は、あまり考えが整理できてない。 最近のウェブ界隈での「インフラ」という用語の使われ方には、色々異論もあるようだけど、ここではごく最近使われるようになってきた、OS からミドルウェアといったソフトウェアレイヤーを指す言葉としてのインフラについて触れる。（英語圏でも同様の意味で使われているようなので、ある程度市民権を得たと言っても良さそうだし。） プロビジョニングレイヤー まず、前提知識としてプロビジョニングレイヤーと自分が勝手に呼んでるものについて整理。 Chef や Puppet は「プロビジョニングフレームワーク」とも呼ばれているが、以下の議論をより厳密にするために、Lee Thompson 氏による
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
