ときどきAnsible日記

主にITインフラ基盤の自動化に関する事を書いているブログです

OSSとOpenStack

お疲れ様です。伊藤です。

・・・すいません。ほぼ1か月以上記事の更新ができませんでした。
個人的な理由(引っ越し)と5月から新プロジェクトに入り何かと追われております(という言い訳)

まあ、言い訳はそれぐらいにしておき、今回はOSSとOpenStackについて書こうかと思います。以前も書いたかもしれませんが、弊社はシステム開発が基本でインフラに疎い人間が多いので、業界の方からしたらかなりしょぼい内容になるかと思いますが、ご了承くださいm(__)m

ちょっと余談僕続くのですが、弊社は5月決算で6月が期初となります。そんな理由もあり期初に決意表明をするのですが、今回はOSSに注力する、という宣言をしました。まあ具体的にはAnsibleとDockerとOpenStackですが。。
やはり企業に属していると(特にIT)自分が配属された現場の技術ばかり追いかけてしまいがちです。というわけでこの辺(2017年のエンジニア求人と求められるスキル需要動向を読み解く | サービス | プロエンジニア)のHPをお借りして2018年ブレイクする技術はこれだ!というわけでAnsibleとDocker、クラウドのbackendとしてOpenStackを持ちあげ、総じてOSSについて注力していきます、というお話をさせていただきました。

で、すいません。ちょっと内輪の話になるんですが、おそらくうちの社員の場合は30%ぐらいは「OSSってなんぞ?」という方がいらっしゃる可能性があるので、ここにちょっと書いて置きたいと思います。

OSSとは
言わずもがなオープンソースソフトウェアのことです。じゃあオープンソースって何?となります。極々簡単に言うと全世界にソースが公開されて、みんなで修正とかできるよ、ってことだと思っています(ご。。。語弊を恐れずに言うと。。。ですが)
当然ソースが公開されているわけですから、利用はフリー、要は昔でいうところのフリーソフトOSSに当たるものが多いです。じゃあ、どうやって設けるの?というとサポート料金とかそのソフトを使ったサービスをラッピングして売り出したりとかそんな感じになる認識です。詳しくはこちら(オープンソースソフトウェア - Wikipedia)
Linuxが世界一有名なOSSかと思っていますが、ちげーよ、という方はコメントください(私の知り合いの方はこっそり教えてください)
なぜ今OSSかというと、Redhat社が近年特にOSSに力を入れていることもあり、世界の大手企業がOSSに非常に力を入れている、というところもあります(Facebookgoogle等々)
先に挙げたAnsibleやDockerももちろんOSSですし、次に上げるOpenStackのOSSです。具体的にはOSSを使ったソリューションになるのかな。。。企業がOSSを導入する理由としてはOSSが成熟して実用性のあるクオリティに上がったというものあると思いますが、ベンダロックインを避ける、技術的なアピールなど色々な理由もあるかと思います。過去のフローソフトという印象はかなり古臭いものとなり、現在は最新技術をいち早く取り入れるためにOSSで開発する、という認識になっています。

OpenStackとは
自社でインフラの話をする際にはかなりかみ砕いで説明をしています。OpenStack辺りは普通にかみ砕いても伝わらないので、かなり簡単に説明させて頂きます。
OpenStackは先にもちょっと書きましたが、OSSのソフトウェアを使ってクラウド環境を構築するためのソリューションになります。クラウド環境とは所謂、AWSとかAzureとかですね。そういった環境を構築するためのツール群と言った位置づけの認識です。(ざっくりすぎ)
7~8年ぐらい前はOpenStackは実用に耐えるものではなく、各社がR&Dを繰り返し、技術をためているという状態でしたがここ数年でOpenStackを利用したクラウドサービスも徐々に増え始めて現状はかなり実用的になっていると思います。


実は私もOpenStackの仕事を始めて現在鋭意勉強中です。いい年こいての新技術なのでかなり苦労しますが、この業界は常に新しいもの(OpenStackももはや新しくはないですが。。。)を追いかける必要があるんですね。。。と実感中です。OpenStackの詳細な内容についてはまた自分の知識がたまったら一般的な内容をこちらに書きたいと思います。

ではとりあえず本日はここまで。お疲れ様でした。

CIとCDについて

お疲れ様です。伊藤です。春を迎えたはずなのになんだかちょっぴり寒い。皆様風邪など引かぬように体調にはお気をつけください。

今日はCI(継続的インテグレーション)とCD(継続的デリバリー)について書きます。
で、まあ自動化といえばCI/CDはよく出ますね。しかし!結局なんなのそれ?よくわかんないんだけど?という方も多いかと思います(ってか私がそうでした)
そんなの常識だろう、という方はそっとブラウザを閉じていただけると助かります。

というわけでここからはインフラの知識ゼロでもわかるCI/CDを目指して書いていきたいと思います!(決意)

CIから行きましょう。まず継続的インテグレーションという言葉が難しい。インテグレーションが継続的ぃ?はぁ?って感じです。直訳にもほどがあるんじゃないのって感じですね。
英語で書くとcontinuous integration....うん、ちょっと忘れましょう。
おそらく当初は大層な意味があったんでしょうが、今は結局「CVSとかgitとかのライブラリ管理ソフトに作ったプログラムを登録したら自動的にテストまで行う」事に尽きると思っています。
もうそれだけかと。それを実行するのがJenkinsをはじめとしたCIツールと呼ばれるものです。要はこいつがライブラリを監視していて、登録されたら事前に予約しておいたシェルを動かす、それだけです。
つまりは

  • 修正ソースを開発ライブラリにコミット
  • ソースをビルド
  • 実行ファイルを開発環境に配置
  • 開発環境のアプリ停止
  • 開発環境へデプロイ
  • 開発環境のアプリ再開
  • テスト用のシェル実行

この流れを自動にするって感じですね。そうすると修正してすぐテストできるから効率上がるぜ!アジャイル開発にもってこい!見たいな感じになるわけですね。


~ある日の開発ルーム~
開発チームのA君:やっとプログラムが動くことまで行ったからテストしようかなぁ。。。でもデプロイは運用チーム担当だから今日の帰り際にお願いして明日テストしーよおっと。
運用チームのBさん:いやデプロイするならちゃんと申請してください。あと業務後なので明日の夜リリースです。
A君:えー。めんどくさいなあ。それぐらいちゃちゃっとやってよ。申請書書くのめんどくさいから明日やろっと。
~そして明日~
申請書は遅れたものの何とか無理を言ってデプロイしてもらう。
A君:あ~また止まった!ちょっと直すからまたデプロイしてもらおう!
~以下無限に続く~
ということもなくなりますね(いいすぎ)
その辺が一体化されることがまさにDev(開発)Ops(運用)の考え方だと思います。


では続いてCD(継続的デリバリー)ですね。こちらはリリースの自動化です。先ほどとほとんど一緒ですが下記の流れを自動化します。

  • テスト完了ソースを本番ライブラリにコミット
  • ソースをビルド
  • 実行ファイルを本番環境に配置
  • 本番環境のアプリ停止
  • 本番環境へデプロイ
  • 本番環境のアプリ再開

の自動化です。こう考えると非常に簡単。ですが、実際には開発対象のアプリケーションの種類によって色々とデプロイ方法も違ったり、再起動対象も代わったりと簡単にはいきません。が、使い込んでいくうちにリリースの人為的なミスは無くなり、リリースまで瞬時に完了するため開発のスピード感が劇的にあがります(たぶん)


まあそんなわけで、CI/CDっていうのは世の中に浸透していると思います。あと今回はすごーく狭義にCI/CDのことを書きましたが、もちろん開発環境でもCDするし本番でCIということもあるかもしれません。私もこの手の環境作ったことが無いのでエアプ感が漂いますが、機会があれば是非構築してみたいと思います。
お疲れ様でした。