2019-03-24

FreeBSDの準仮想化機構「jail」によるコンテナホスティングプラットフォーム「jaisting」を公開しました

FreeBSD

f:id:zhimrock922:20190324212201p:plain — jaisting

はじめに

お久しぶりです、筆者です。この度、この度、FreeBSDの準仮想化機構「jail」によるコンテナホスティングプラットフォーム(以下、プラットフォームをPFと呼ぶ)「jaisting」をパブリックにリリースする事になりましたので、リリース記事をここに執筆します。なお、以前のプロトタイプ向けの記事はこちらをご覧下さい。

himrock922.hatenablog.jp

開発経緯について(改めて)

パブリックリリースにあたって、改めて開発経緯について執筆します。現在、ちょくちょく参加させていただいているFreeBSD勉強会においてiocageと呼ぶjail管理ツールの事を聞きました。 iocageはFreeNASを開発しているチームを中心に開発されています。iocageは非常に簡単にjailシステムを作成・管理する事ができます。筆者も当初はiocage上で用意されているバックエンドライブラリ側を利用して開発に至っていましたが、CLIと混在していること、Pythonコードを読むのも実は初めてであるという様々な諸事情があり、コードの理解に難航する事が多々ありました。そんな中、iocageのPRから派生したバックエンド専用ライブラリプロジェクトであるlibiocの事を知り、Contoributersとも相談(?)した事により、今回のプロジェクトではlibiocを採用する事としました。現在、こちらのバックエンドライブラリの改修に関しても並行して行っております(まだmergeはされていませんが)

そもそもの開発経緯としては、筆者はこれまでDockerを中心としたコンテナ管理を仕事として行なってきたのですが、近年発表されているコンテナオーケストレーションツールを触りつつも、大規模なコンテナオーケストレーションを行うような実績・経験がない事、UI的にも不満が残るところがあること、そもそもコンテナオーケストレーションツールが必要なアーキテクチャというのがどういうものなのか、VMでクラスタリングしていた時と比較しての優位性が感じられなかった等の様々な疑問があり、あまり馴染めないところがありました。更に、今までFreeBSDを触りつつも貢献できていない罪悪感に駆られ←、Web開発とコンテナのノウハウから何かできないと思いつつ、開発を進める事としました。

今後の展望

今後の展望ですが、FreeBSDの機能を潤沢に使いプラットフォーム経由でフラットにコンテナ作成・管理、ネットワーク作成、NAT、FWの機能を設定できるようなPFを目指します。また、一応ライバル(と言うのもおこがましいですが)となるツールはKubernetesというところもあり、闘っていくという所まではいかないかもしれないですが、一先ずスケーリング機能はホスティングPFと言えども関係なく採用したいと思います。

現在サポートしている機能

jail作成・起動・停止・削除機能 jailコンテナをPF経由でフラットに管理できるように上記4つの機能を導入しました。
IPv4アドレス設定機能 jailに紐付けさせるブリッジインタフェースとL3レベル(プライベートな)で疎通が取れるようにIPv4アドレスをvnetインタフェースに紐付けられる設定をフォームから行えるようにしました。
FreeBSDソースの取得

jailを作成するにあたってFreeBSDのソースを取得する機能を追加しました。

機能要件

FreeBSD 12-RELEASE 以上

12以降、vimageをデフォルトのカーネルでサポートしているため、12-RELASE以上とさせていただきます。

Python3.6以上

libiocやDjangoを利用するためにPython3.6以上をインストールしてください

Django

PFを構築するためのバックエンドフレームワークとして利用しています。

yarn

フロントエンドはDjangoとは独立して構築していますので、フロントエンド関係のパッケージをインストールするためのパッケージマネージャーとして必要となります。

postgresql-server

現在、libioc側でjailの設定を保存しているのでほぼDBにデータを格納しておりませんが、ログインデータはDBサーバに保存するように設計してありますので、面倒ですがインストールしていただけますと幸いです。

その他の必要なパッケージはREADMEをご覧ください。

ソースコードについて

最後に、jaistingのリポジトリを共有します。

github.com

まとめ

という事で初パブリックリリースとして改めて、まとめ記事を書きました。今後もサポートしなければならない機能が多々あり時間との戦いでもあります。とは言え、フラットにコンテナ管理ができるPFとして魅力的なモノを作っていくので応援のほどよろしくお願いします。また、開発に協力して下さる方も募集しておりますで、ご興味があれば是非PRやissueを送っていただけますと幸いです。

それではまた。

参考文献

2019-01-15

FreeBSDのjailホスティングシステム「jaisting」を作りました

FreeBSD

はじめに

お久しぶりです、筆者です。この度、FreeBSDの準仮想化機構「jail」によるコンテナホスティングシステム「jaisting」をリリースする事になりましたので、リリース記事をここに執筆します。

jailについて

jailとは、OSレベル仮想化機構の一つであり、ホストマシンとは独立した小さなシステムでFreeBSDを動かすことができる機能です。LinuxではDockerが有名になってしまいましたが、jailは古くからFreeBSDで実現されています。今回開発したシステムはこのjailをホスティングできるWebアプリケーションを開発しました。

開発経緯について

現在、ちょくちょく参加させていただいているFreeBSD勉強会においてiocageと呼ぶjail管理ツールの事を聞きました。 iocageはFreeNASを開発しているチームにより開発されています。iocageは非常に簡単にjailシステムを作成・管理する事ができます。また、iocageのライブラリ版であるlibiocageも非常に強力なjail関連のコマンドを実行することができるWrapperが既に実装されており、このライブラリとWebフレームワークと組み合わせる事で、非常に柔軟にjailシステムをWeb上で構築できるようになると考え、今回の開発に至りました。

また、筆者はこれまでDockerを中心としたコンテナ管理を仕事として行なってきたのですが、近年発表されているコンテナオーケストレーションツールを触りつつも、大規模なコンテナオーケストレーションを行うような実績・経験がない事、UI的にも不満が残るところがあり、あまり馴染めないところがありました。更に、今までFreeBSDを触りつつも貢献できていない罪悪感に駆られ←、Web開発とコンテナのノウハウから何かできないと思いつつ、開発を進める事としました。

設計思想・今後の展望について

設計思想的にはスケーリングやデプロイと言ったようなコンテナオーケストレーションツールというよりは、1アプリケーション1コンテナのようなミクロなサービス運用を行う時の助けになればという思想です。コンテナオーケストレーションはもうKuberneteus一強となりそうなところがありますので、その上でこちらもコンテナオーケストレーションツールとして開発していくのは辛みしかありません。また、しつこいですが筆者自体がコンテナオーケストレーションが必要となるようなソフトウェアアーキテクチャというのがそもそも想像つかない、それならバックボーンから見直すわ(勿論、バックボーンを設定できる権限があればの話ですが)派なため、それであればコンテナ関連のソフトウェアとしてはホスティングの方で開発していこうというのが最初の設計思想です(さくらインターネットもDockerコンテナホスティングサービスであるArukasをやっているのでもしかしたら需要もそこそこあるかもしれませんね)。

そのため、今後スケーリングやデプロイと言った機能を入れるかどうかはかなり微妙です。しかし、FreeBSDにはjail以外にもネットワークスタックをホストマシンに紐づく物とは独立して作成できる機構vimageもありますので、今後は仮想ネットワークスイッチやルータと言ったネットワーク機器の設定、およびjailと連携させてホストマシンとjailシステム間のネットワークトポロジを柔軟に構成できるような機能も作っていきたいと思いますので、今後とも応援よろしくお願いします。

機能要件(徐々に書いていきます)

FreeBSD(物理サーバーでもVMでも構いません)

現在の機能

UI上で触れる機能としては、jailシステムの作成・削除・起動・停止・jail設定の詳細を閲覧できる機能しかありません。今後とも機能追加をしていきます。

UIサンプル

f:id:zhimrock922:20190115222541g:plain

ソースコードについて

現在、プライベートリポジトリにおいて開発を進めています。詳しく知りたい方は私のプロフィールまでご連絡のほどお願いします。

GitHubアカウント

参考文献

2018-12-31

今年の読んだ本まとめ

はじめに

今年も終わりですね。3月にWeb受託開発のSIerを辞めて、4月から渋谷のインフルエンサーマーケティングを行なっている会社に入社致しました。勤務時間や場所が変わり、またウォータフォールからアジャイルに開発プロセスも変わり、現在非常にやりがいがあります。更に、会社で仕事を行なっていくにあたって、仕事に必要な勉強、また自分でサービスを作るにあたって、そして今後の自分のキャリアに向けての勉強をできるようになってきたので、今年の締めとして今年読んだ本を紹介していきたいと思います。

リーダブルコード

プログラマとして働く人間が絶対読まなければいけない定番のような本です。惜しくもようやくこの年代になってですが、読めるようになってきました。仕事を行うにあたって、自分に足りなかったのが「リファクタリング」です。そういう意味では、現場の問題点からこういう風にコードを改善していくべきというお作法が述べられているこの書籍は非常に勉強になる本でした。この本は一家に一冊(?)は持っておくべきでしょう。

プログラミング作法

リーダブルコードと同じく、プログラマとして働くために必要な本です。こちらは現場からの問題点から改善案を出していたリーダブルコードと打って変わり、プログラミング作法は情報科学に基づいた知見からコードの改善をしていくにはどうすればいいのかがまとめられている本です。少し読むのが難しい所もありましたが、必要な時に応じてこちらも一冊手元に置いていくのがいいかもしれません。

HTTPの教科書

HTTPの基本的な知識を深めるために、この本を読んでいました。ステータスコードの一つ一つの用途を説明した章は省略していますが、より詳細な部分はRFC(Request for Comments)を読んで補う前提でこちらの本でHTTPの基本的な知識を学ぶのが良いかと思われます。

Webエンジニアのためのデータベース技術[実践]入門 (Software Design plus)

Software Designでデータベースのコラム特集を一冊の本にまとめたものです。古い書籍ではありますが、MySQL,PostgreSQLなどのソフトウェア固有の知識よりも、そもそもデータベースを使う理由とは何か?テキストファイルやExcelファイルを使うよりもデータベースを使うメリットとは何か?と言ったデータベースの基本的な知識を学ぶためにこの書籍を購入しました。

コーディングを支える技術 ~成り立ちから学ぶプログラミング作法 (WEB+DB PRESS plus)

言語特有の機能を学ぶよりも、そもそもどうしてこの言語が開発されたのか?今までどのような問題点があって現在のような高級言語が開発されたのか?そのような事を学ぶために非常に有意義な本です。この本を読んで以降、私は言語やフレームワークの教本を購入するのは辞めました。何故かと言うと、それはインターネットで検索すれば大体メソッドの説明やメソッドのソースコードが読めるからです。そしてそのような言語特有の知識が必要になってくるのは、ほぼリファクタリングの時だけだからです。そういう意味では、この本を読んで必要な知識を勉強する部分がある程度決まったような気がします。

この本を執筆した著者の新たな本があるので、近いうちに読もうかと思います。

マスタリングTCP/IP 入門編第5版

言わずと知れた、ネットワークの基礎的な知識を身に着けるためには非常に良い教本です。私は元々ネットワーク分野の研究をしていましたが運用が嫌いなため、どうしても勉強するのが苦しかった覚えがあります。現在は、私自身がネットワーク嫌いというのを割り切っているため、今のネットワークプロトコルやアーキテクチャに異議あり!という精神で勉強する事が出来ました。そして、私はLayer 3のプロトコルや技術が本当に嫌いだという事もこの本を読んで確信しました(というか、ここ最近Layer 3を外したいと言うエンジニアをよく耳にするので、そもそもLayer 3の役割って何だっけ?と復習するのにも良いかもしれません)。

まとめ

と言う訳で今年読んだ本の紹介でした。この年になってようやく自発的に勉強できるようになってきたので、来年はもっと読む書籍を増やす、良い本を選別できればと思います。それでは、皆さん良いお年を

2018-09-30

SIerは3年までやっても良いけど3年以上やってはいけないというか3年以上もたない

業界

f:id:zhimrock922:20180930001558p:plain

はじめに
そもそもSIerって?
経歴
なぜSIerは3年持たないのか
でも新卒の子がSIerに3年間入るのは賛成
まとめ

はじめに

9月も終わりもうすぐ10月ですね。中途入社した会社がそろそろ在籍半年になりそうなので、色々と今日までの人生を振り返ってみて、やっぱ自分がSIerで働くのはもうこれ以上無理だな...と悟りました。よくこういうSIer vs Web比較エントリというのは見受けられるかと思いますが、生々しい元Sierの声ということで聞いていただけると幸いです(ということなので、実際ほぼSIerの愚痴になります)。

そもそもSIerって?

www.weblio.jp

要は、SI(システムインテグレーション)を行う人のことで「-er」と呼んでいる訳なのですね。 SIとはユーザーの課題を解決するようなシステムの企画・開発・運用サポードなどの業務を行う事です。ただし、課題解決のための業務というのはIT企業の業種には他にも存在し、コンサルタント、システムエンジニアと明確に切り分けをするのが難しい業種です。私の場合は一先ず、問題解決と言われるとそのイメージからコンサルタントがパッと思い浮かぶので違いは無いと思っています。続いては僕の経歴です。

経歴

2015年4月〜 2015年9月某Sierに新卒で入社。データセンター保守業務に関わるが半年で退職。
2015年10月〜 2018年3月某Web受託開発会社に入社。インフラ運用・保守とWeb開発の兼用。
2018年4月〜渋谷の自社サービスやっている会社に入社。現在に至る。

とまぁ、こんな感じです。この経歴のように一応SIerは新卒の会社半年とWeb受託開発会社2年半年でちょうどきっかりSIer業務を行っていた訳です。よく、Web業界とSIer業界で比較エントリとか見られると思うのですが、「それなら二社目もWebじゃないのー?」と思う方もいるかもしれません。しかし、SIの定義ではあくまで「ユーザーの課題解決するようなシステムの企画・開発・運用サポートなどの業務を行う」ことなので、そういう意味では私は業界は関係ないと思っています。そのため、二社目も受託開発をメインとしてやっている立場上SIerと言っても良さそうです。 1社目を辞めた理由はキャリアチェンジしたかったため。そのため、僕がSierとして働いた身分として話せそうなのは実質2社目の中身でしかないのですが。ひとまず、次になぜSIerは3年もたないのかその疑問に対しての回答を投げていきます

なぜSIerは3年持たないのか

案件が似たり寄ったり

SIerは、しつこいですが基本的には、「ユーザーの課題解決するようなシステムの企画・開発・運用サポートなどの業務を行う」人のことを指します。つまりは、会社としては自社で何か製品を作る訳ではない、るいはそれをメインとせず受託や客先常駐をメインとしている会社となります。よくSIerで働くメリットで「多種多様な案件に関われて、それが成長につながる」とか言われてますが、これは経営者からすればそうかもしれませんがエンジニアからすれば微妙な話です。 2社目の受託開発の会社はRuby on RailsによるWebアプリケーションの開発を得意としている会社でした。またその会社は案外歴史が長く(設立して10年程度)、当初から受託開発によるWebアプリケーション開発を行っていました。当初まだWebフレームワークによるWebアプリケーション開発がまだ主流ではなかった頃からの受託開発を進めていたこともあり、多くの案件がふってきているのは間違いありませんでした。しかし、その来る案件は殆ど同じような似たり寄ったりのバックエンドで動かす管理画面を作るような案件しか存在せず、新鮮味が徐々に薄れていってしまった所があります。

リファクタリングできる機会を失う

幸か不幸か僕は純粋な一次案件、及び二次案件でも設計から携われる案件というものが多く、そういう意味では純粋なウォータフォール型の開発プロセスに携わることができたと言っても過言ではありません。ウォータフォールについては以下のサイトを

ウォーターフォール・モデル - Wikipedia

SIerの業務上、どうしてもウォーターフォール型の開発プロセスで回していくしかないのは仕方がないですが、このウォーターフォールでは納品後には基本的にコードは触りません。もちろん、納品した後には瑕疵担保責任というものが発生するため、問題があり次第コードはメンテナンスしますが、設計書通り行っていたのであれば基本的には起こりえません。瑕疵担保責任の考え方についてはこちら

www.tokyo-cci-ict.com

いずれにせよ納品したソースコードについては基本的に触らないようにするのが鉄則です。第一納品完了した後のコードって触りたいですか?瑕疵担保責任があるため、それが発生するまでは触らない方が良いし、プライベートでリファクタリングなんて以ての外。守秘義務もありますしね。勿論、実装中にリファクタリングすることもありますが、いずれにせよウォータフォールではどうしても基本的なプログラミング作法や納品までの仕事のやり方を学べる程度なので、すぐに得られる知見は頭打ちになってきます。それに引き換え、リファクタリングは本当にプログラマーとして必要なスキルが身につきます。コードは人が読むものです。その人が読みやすくなるコードを書くためには60点のコードではいけない訳で、100点に近づける必要があります(また、どこかで良いコードを書くための知見を共有したいですね)。

人間関係が最悪

よく、SIerの悪い部分で言われる「Excelシートでエビデンスやタスク管理が嫌」とか「使われている技術が化石」とか言われますが、正直僕はそれはあんまり問題にならないと思っています。なぜなら、これは会社や案件や部署によりけりだからです。私が以前いた会社でもレガシーなRailsアプリやPHPアプリを運用することもありますし、タスク管理をExcelシートで使っている部署もありました。そのため、これはSIerで働いていればまぁ仕方がないかなと思っています。会社もちゃんと売り上げ立てないといけないですしね。僕は正直言うと、SIerの人間関係は非常にギスギスしている、、、むしろそっちの方がSIerの最大の問題点だと思っています。お客さんが会社だからですかね、「仕事が丁寧」なのと「重箱の隅をつつく」のを一緒だと思っている人がまぁ多いこと。

正直、前職の退職理由の9割がほぼこれで更にトリガーになったのが、そんなギスギスした人間関係が生まれているのに、一方的に僕のコミュニケーション能力が足らないと僕だけに問題があるような返し方してきたので、じゃあもう良いですってことで退職しました。はい、という訳で愚痴になりましたが、こういうこともあるので基本的にはSIerは客層のお陰で良く言えばちょっと神経質で、悪く言えばヒステリックな人間が多いです。

でも新卒の子がSIerに3年間入るのは賛成

最後に、でもSIer自体には入社して良かったと思っています。なぜなら僕が就職する際に何がしたいのか分からなかったため、基本的な仕事の流れやうまく仕事をこなしていくにはどうすれば良いのか考えるとやはりSIerやコンサルタントの問題解決能力ってすごく重要になってきます。極論、SIerやコンサルタントの能力ってIT業界に止まらずどんな仕事でも必要になってくる能力だと思っています。そのため、新卒の学生の子でまだ目標が明確ではない子がSIerやコンサルタントを行っている企業に入社するのは賛成しています。石の上にも3年と言うのは信じないという人もいるかもしれませんが、ある種仕事を上手くこなす為には、それくらい時間かけないと会社としても仕事を「こいつに任せて良いのだろうか?」という疑問を抱くのは当然ですし、そう言った意味で、経験と慣れを蓄えた方が良いです。その後、自分の興味のある分野に飛び込むのも悪くないかもしれません。

しかし、SIerの仕事上どうしても3年以上は仕事のマンネリ化が否めないので3年に近づいたらそろそろ自分の目標を考えて動いた方が良いかもしれません。

まとめ

という訳でSIerは3年までやっても良いけど3年以上やってはいけないというか3年もたないというお話でした。極論、僕がSIerの仕事に向いていなかったという話になっちゃいましたが、あんまり我慢せずにしかし気遣いはとても重要なのでそこのバランスを取れればなんだかんだ言ってどこでも通用するかと思います。まだ社会人経験浅いですが汗それでは。