Furyu
[フリュー公式]

Tech Blog

フリュー株式会社の技術ブログです

2018年09月20日

Kayo

sshfsを使ってみました!

みなさん、こんにちは。ピクトリンク事業部インフラ課の藤本佳世です。
今回は、使ってみてとても便利だった「sshfs」をご紹介したいと思います。

sshfsとは

SSHを経由して、他のサーバのディレクトリをマウントすることができるコマンドです。

なぜ便利なのか?

私は日々の業務でよくAnsibleを使ってサーバのミドルウェアのインストールや設定などを行います。
※Ansibleについては、以前ブログを書いているのでこちらをご覧ください。

 

今までは自分のローカルUbuntu環境からAnsibleを実行していたのですが、Macから実行すると環境違いでエラーになる事などがありました。
この状況を解消すべく、インフラ課のメンバー全員が同じ環境でAnsibleを実行できるよう専用サーバを構築しました。しかし、ローカルとリモートのコードを2重で管理という面倒な仕様になってしまい、何か解消する方法はないかと悩んでいました。

blog1

そんな時見つけたのが「sshfs」です。
これを使ってリモートで直接コードを修正しつつ、ローカルでのデバッグ実行も可能となり、とても便利になりました。

NFSと比較した場合、リモートサーバでコマンドを実行する(=SSHでログインして実行する)環境が既にできあがっているので、ローカル側にプログラムをインストールするだけで実現可能というお手軽さもあります。

使い方は簡単

  • sshfsのインストール(Ubuntuの場合)

  • マウント方法

例として、私のローカルマシーンの/testというディレクトリを作成し、サーバserver1の/home/fujimoto.kayoディレクトリをマウントします。

あとは、sshfsコマンドをローカルマシーンから実行するだけです。

これでマウントができた状態です。実際にサーバserver1の/home/fujimoto.kayo配下には、example-ansibleディレクトリが存在しますが、
ローカルマシーンの/test配下にも同じexample-ansibleが存在します。

  • アンマウント方法も簡単

最後に

コードの2重管理がなくなったり、コードの修正をローカルで使い慣れている環境のエディタで編集できたり、ちょっとした工夫で日々の業務がスムーズに行えるようになりました。

是非、皆さんもこの「sshfs」を使ってみて下さい!


2016年05月27日

Kayo

テスト環境にOpenStackを導入しました!

みなさん、こんにちは。コンテンツ・メディア第1事業部インフラ担当の藤本佳世です。 少し前になりますが、テスト系環境にOpenStackを導入しました。OpenStackを聞いたことがない方も安心して下さい。これから構築手順やTipsなどご紹介できればと思っています。今回は1回目「OpenStackとは?」についてお話ししたいと思います。今後、下記の内容をブログに投稿する予定です。

  • OpenStack構築手順
  • ネットワーク設定  ※高可用構成やFloatingIP割り当てなど
  • 仮想マシンの起動や管理について  ※イメージやフレーバーの作成など
  • セキュリティグループについて ※追加や削除方法など
  • つまずいたこと

What is OpenStack?

OpenStack とは、簡単に説明すると、プライベートクラウド環境でAmazon Web Services(以下AWS)のようなものを構築可能にしたソフトウェアです。AWSを使ったことがない方に向けて、もう少し詳しく説明すると、OpenStackを使ってプライベートクラウド上に仮想サーバやネットワーク、ストレージなどを構築することができます。そして、それら作成したものはダッシュボードの Web インターフェースから管理することができ、GUI上で簡単に仮想サーバを構築することができます。
その他にもOpenStackは、DockerやAnsibleなど構成管理ツールとも連携することができ、より効率よく短時間で用途にあったサーバを構築することができます。

OpenStack導入でサーバ構築時間を短縮

openstack導入1

openstack導入2

OpenStackを導入することにより、サーバの構築時間を今まで以上に短縮することができました。開発メンバーから、「新技術の検証環境として新しいサーバが欲しい」や「新しいサーバを購入するほどではないけど、検証用にサーバが欲しい」など要望があった場合、今までサーバが届いてから3時間ほどかかっていた構築作業が、10分以内で可能となりました。構築が早くなったことで、開発メンバーを待たせることなく、気軽にサーバ構築依頼をしてもらえるようになりました。

7つのコンポーネント

OpenStackは7つの機能から構成されます。

  1. Nova (仮想マシンの提供と管理を行う)
  2. Keystone (ユーザー認証・管理を行う)
  3. Horizon (Webブラウザ経由で管理・操作できるGUIコンソールを提供する)
  4. Glance (仮想イメージの管理を行う)
  5. Cinder (仮想マシンが使用するストレージ管理を行う)
  6. Neutron (仮想ネットワークの管理を行う)
  7. Swift (クラウドストレージを提供する)

OpenStack構築内容

ホストOS: Ubuntu14.04LTS (8台構成), OpenStackバージョン: Liberty

  • サーバ1:Nova,Keystone,Horizon,Glance,Cinder
  • サーバ2:Nova,Keystone,Horizon,Glance,Cinder
  • サーバ3:Nova,Glance,Cinder
  • サーバ4:Nova,Glance,Cinder
  • サーバ5:Nova,Glance,Cinder
  • サーバ6:Nova,Glance,Cinder
  • サーバ7:Neutron
  • サーバ8:Neutron

※Swiftは未検証

ホストOSのUbuntuインストールは、前回ご紹介したPXE機能を使って構築しました。
前回の記事はこちらへhttp://tech.furyu.jp/blog/?p=3858

次回は、各コンポーネントの説明と構築手順をご紹介したいと思います。


2015年01月8日

kunihira

GitBucketでコードレビュー

GitBucketGit

明けましておめでとうございます。国平です。 久々の投稿となってしまいましたが、今年も元気に開発して、たまったノウハウをこのブログに投稿していこうと思います。

今回は、以前ご紹介したGitBucketに、みんなが渇望していた あの機能 が追加されて、嬉しさのあまりブログ記事にしてしまいました。

GitBucketのおさらい

  • GitBucketは@takezoen さんが開発してOSSとして公開されているGitHubクローンのWebアプリです
  • Scalaで書かれていて、単体のjarでも実行できるので、お試し導入が非常にしやすいというメリットがあります
  • GitHubのクローンなので、GitHubでできることは大体できます
  • ただ、version2.6までは、コミットに対してコメントする機能がありませんでした

というのが、GitBucketの主な特徴でした。 なので、社内で利用するのに最適なGitHubクローンと言えます。

ついに登場したコメント機能

つい先日、2014年12月29日にGitBucketの最新バージョン2.7がリリースされました。 @takezoenさんのブログでも目玉機能として紹介されていますが、 ついに、コミットおよびdiffへコメントを付与する機能が追加されました。

これによって、ついにGitBucket上でプルリクエストをコードレビューしてマージすることができるようになりました。

さっそく使ってみる

早速、GitBucket内のリポジトリで管理しているドキュメントをちょっと修正してプルリクエストを出してみました。 ご覧のとおりプルリクエストの画面にコメントが一覧表示されています。

PullRequest


このうち、一番下のコメントは、

InLineComment

コミットのDiff表示内にインラインで投稿したコメントでしたー


ということで、完璧です。完璧すぎます。

まとめ

というわけで、ついにGitBucketにコメント機能が追加されました。 これで、社内OSSが活性化すること間違いなしです。(ほんとか?)

GitBucketを導入されている方は早急なアップデートを、導入検討中の方は早急な導入をオススメします。 特に、既にGitBucketを導入されている方は、 MarkDownに関するセキュリティ問題の修正が含まれているそうなので、早めにアップデートした方が良さそうです。

今回のバージョンのその他の内容については、Issueの一覧にまとまっています。

おまけ

コメント機能の中身

以前は、GitBucketにコメント機能を追加するには、かなりJavaScriptでがんばる感じになるんだろうと思っていました。 実際、@takezoenさんも2.7のリリース記事内で

と、jsについて言及されています。

しかし、コメント機能のコミットを見ると、意外とJavaScriptの変更は少なかったです。

GitBucketインストールのAnsible化

インラインコメントの画像に書いてますが、GitBucketのインストール/アップデートをPlaybookにまとめようと思います。 最近、ScalaよりAnsibleのPlaybookを書いてる時間の方が多いので、勢いに任せてやってしまって、いずれここでご報告しようと思います。 (ひょっとしたらもう誰か公開されてるかもしれませんが、勉強のため自作します)

関連記事


2013年09月11日

kunihira

Packer+Chef-SoloでAMI作り

こんにちは。 自称Chef導入委員長の国平です。
立て続けの投稿になってしまいますが、今回はPackerの紹介記事を書かせて頂きます。

仮想マシンイメージの作成ツールであるPackerがChef-Soloからのマシンイメージ作成に対応しました。 今回は、その機能を利用して、AWSのEC2 AMIを作成してみます。

Packerとは

仮想環境のマシンイメージを作ってくれるツールです。 一つの設定を元に複数のプラットフォームに対してマシンイメージを作成出来ます。 シェルスクリプトやChef-Soloを使ってマシンイメージを構築します。

ChefやAnsibleの様なプロビジョニングフレームワークはマシン環境の構築にとどまらず、EC2の操作などかなり幅広く利用出来ます。反面、それらのツールで実行する役割を増やすほど設定が複雑化してしまいます。しかし、Packerを利用するとマシンイメージの作成をPackerにまかせることができ、ユーザはマシン設定に集中する事が出来ます。

Packerの利点

Packerを利用する事で以下のメリットを得られます。

  • インフラ構築の高速化
  • 複数プロバイダー間の連携
  • テスタビリティの確保

インフラ構築の高速化

Packerを利用する事で、そのマシンイメージの作成コストを下げることができ、マシンイメージを起動するだけで、利用可能な環境を手に入れる事が出来ます。

複数プロバイダー間の連携

PackerはAWS, VirtualBox, VMWareなど複数のプラットフォームに対応しています。Packerの設定一つで、AWSとローカルマシンの両方に同じ設定を行ったマシンイメージを作成する事が出来ます。 それぞれのプラットフォーム間の違いは、Packerが吸収してくれるので、最終的なマシンイメージを統一して用意する事が出来ます。

テスタビリティの確保

Packerを使う事で上記のように複数のプラットフォームにマシンイメージ作成できます。 そのため、一つの環境でテストを行う事で、他の環境が期待される結果になっている事を保証されます。

気に入った機能

個人的に気に入った機能が、fixコマンドです。 Packerがバージョンアップした際に、古いバージョンのJSONを新バージョンに変換してくれます。 変換結果は、標準出力に吐き出されるので、Linuxであれば以下のコマンドで、最新のJSONを取得できます。

一度書いた設定が動くことが保証される、もしくは、容易に動く状態にできるというのは、運用が長期化したり、運用するサーバ設定が複数ある場合に非常に助かると思います。

インストール

UNIX/Linuxでは、~/packerもしくは/usr/local/packerにインストールすることが推奨されています。 インストールするためには、公開されているzipファイルをhttp://www.packer.io/downloads.htmlからダウンロードし、解凍しパスを通します。

Linuxマシンに対してインストールを行うには以下のコマンドを実行します。 ご利用の環境に応じて、適宜ダウンロードURLは変更してください。

正常にインストールが完了し、パスが通っていれば、packerコマンドを実行すると以下のように、表示されます。

Macの場合は、Homebrewを使ったインストールも可能なようです。 詳しくは、公式サイトを参照してください。

とりあえず使ってみる

Packerを使って、NginxをインストールしたAWSのAMIを作成してみます。 まずは、以下のJSONを作成します。

ami-shell.json

builders には、どの様なマシンイメージを作成するかを設定します。 今回はAMIに設定するために typeamazon-ebsにし、resionなどの設定をしています。 access_key, secret_keyは、それぞれAWSアカウントで作成して入力します。

provisioners には、作成するマシンイメージに対して行う処理を設定します。 まずは、Packerの動作を確認するために、typeにshellを指定し、シェルスクリプトを実行してNginxをインストールしてみましょう。

JSONを作成したら以下のコマンドを実行します。

これでAMIの作成が開始されます。 AWSのConsoleから、EC2が起動する事が確認出来ると思います。 EC2が起動すると、provisionersで指定した通りのシェルが実行されます。 yumコマンドが実行されNginxがインストールされると、AMIの作成に入ります。 最終的にAMIが作成されると起動したEC2インスタンスはterminateされます。 ami_nameに指定したように、”Packer-“後にタイムスタンプが追加された名前のAMIが作成されます。

ProvisionarsにChef-Soloを利用する

Packerのバージョン0.3.6からProvisionersにChef-Soloを指定出来るようになりました。

Packer|ChangeLog

下準備 – 実行するChef Recipeを用意する

まずはChefRepositoryを用意します。 今回のお題もまたまたNginxをソースからインストールします。 レシピの準備を手軽に実施するために、Berkshelfを利用してChefRecipeを取得します。 Berkshelfについては、以前の記事や、以前の発表資料で紹介しています。

Berksfile

これで、site-cookbooks内にNginx Recipeと、Nginx Recipeが依存するRecipeが用意されます。 実行後はpacker-sampleフォルダ内は以下の状態になっていると思います。

Packer設定ファイルの用意

Chefリポジトリが用意出来たので、次にPackerの設定ファイルを記述します。 今回は、EC2 AMI を作成するので、以下のようなファイルを作成します。

ami-chef.json

provisioners には、Chef-Soloを利用するので、typechef-soloを指定し、cookbookのパスや、run_list、attributeを書いたJSONフィールドを設定しています。

まとめ

実は以前にPacker+Chef-Soloと同じ事をしてくれるフレームワークを自作してたりしてました。(ec2_automation)

しかし、当たり前ですがPackerの方がずっと使いやすいです。

  • 複数のプラットフォームに対応
  • Chef-Solo以外のProvisionerも利用可能

など、Packerの優位な点が非常に多くあります。 非常に素性がよく、設定も書きやすいので環境構築の自動化と高速化に取り組まれている方々にはPackerは非常にお勧め出来るツールです。

つい先日バージョン0.3.7がリリースされ、新たにPuppetをProvisionerとして利用出来るようになりました。 開発が活発でこれからどんどん便利になって行く事が期待出来ます。