Lum’s

勉強中の技術をまとめるブログ。たまに趣味も。

itamaeでVagrantの仮想マシンをプロビジョニングする

とても久しぶりですが・・。

掲題のように、構成管理ツールであるitamaeでローカルに簡単に開発環境を作成できるようにしたいと思い、やってみたのでメモ書き程度であるがまとめ。

ちなみになぜやるのか

  • もっと手軽にメンバーをジョインさせたい

    • まあこれがほぼ全てで、ある程度経験のある人だったらいいけど、非エンジニアのメンバーとかが開発もやってみたい！となった時に開発環境整えるのが壁になりそう・・と思ったから。

    • もちろん開発環境整えるのもそれはそれで勉強になる一面もあるが・・。

  • 構成管理ツールを触ってみたかった

    • 個人的なところでいえばこれもある。ansibleとかchefみたいなものでも良かったが、rubyで書けてかつ知り合いが使ってたのをみて、まあitamaeでもいっか、という感じで選んだ。

前提

手順

①recipe.rbを用意する。内容は何でもよくて、とりあえず今回は

package 'nginx' do
  action :install
end

とか書いておく。ちなみにitamaeチートシートは

qiita.com

を確認するのが良いかと。packageはactionに対してinstallを設定すればそのままインストールの命令となる。

②itamaeコマンドを打つ

 gem install itamae

でitamaeをインストール後、

itamae ssh --vagrant --host ホスト名 -u vagrant -i 秘密鍵のパス recipe.rb

で、VMの仮想環境にrecipe.rbの内容が実行されていく。

なお、ホスト名はvagrantFileのconfig.vm.network "private_network"の値を、秘密鍵のパスは

vagrant ssh-config

で確認できる。

ちなみに、この通りにコマンドを打つともしかすると設定によってはvagrantユーザーではインストール権限とかがなかったりするかもしれないが、その場合はexecuteを使ってコマンド指定で行けばいいと思う。

なお、今回はローカルで実行→仮想環境に対しプロビジョニングという方向で実行したが、

仮想環境にrecipeをマウント→仮想環境上で

itamae local recipe.rb

とかでもいいと思う。でもそれをやるには仮想環境上でrbenvやらrubyやらを入れなきゃいけないので(itamaeを入れるため)、どうせなら1回コマンド叩けば全部やってくれた方が手間少ないよね、ってことで上記方針を取った。

とても簡潔ですが参考までに。

Railsエンジンを使ってシンプルなアプリケーションをマウントしてみた

なかなか保育業務支援アプリケーション制作の具体的な内容に入れないが、自主学習のため今日はRailsエンジンについて自分なりに学んでみる。

Railsエンジンとは?

少し古いけど、Railsエンジンとは？ということで以下の記事がわかりやすかった。

d.hatena.ne.jp

自分なりの解釈でいくと、２つのRailsアプリケーションがあった場合や、1個のRailsアプリケーションが肥大化していった時などに、その片方やもしくは1個のアプリケーション内の機能をエンジンを使って１つにまとめる（親子の関係にする）ことができるというもの。

gemなどのプラグインとは異なり、エンジンが独自のrouteやlocaleを持つことができたり、親アプリケーションのhelperなどもエンジンから呼出せたりするそう。 上記を読んでいて思ったのは、例えば管理画面が２種類あるようなアプリケーションの場合。

今職場で開発しているアプリケーションってほぼ同じ機能だけどみるDBを分けるために同じものを複製するような形で作った記憶があって、それってメンテナンス性からいうと結構微妙な気がする。そういう時にエンジンとして分けておいて、一ついじるだけで済むようにすればいい感じにいけるんじゃないかな、とちょっと思った。 （違うかもしれない。）

実際にやってみた

まあとにもかくにも、実際に触ってみてなんぼだなと思うので

qiita.com

上記のサイトを見ながらRailsエンジンに触れていく。

$ rails new kinoko_engine

まずは適当なrailsアプリケーションを作成する。 そして

$./bin/rails plugin new board_engine --mountable -T --dummy-path=spec/dummy_app

を実行すると、appフォルダと同階層にboard_engineフォルダが生成される。 そして、board_engine.gemspecを開いてみると、

$:.push File.expand_path("../lib", __FILE__)

# Maintain your gem's version:
require "board_engine/version"

# Describe your gem and declare its dependencies:
Gem::Specification.new do |s|
  s.name        = "board_engine"
  s.version     = BlogEngine::VERSION
  s.authors     = ["username"]
  s.email       = ["email"]
  s.homepage    = "TODO"
  s.summary     = "TODO: Summary of BoardEngine."
  s.description = "TODO: Description of BoardEngine."
  s.license     = "MIT"

  s.files = Dir["{app,config,db,lib}/**/*", "MIT-LICENSE", "Rakefile", "README.md"]

  s.add_dependency "rails", "~> 5.1.6"

  s.add_development_dependency "sqlite3"
end

おお、確かにできている・・！ 上記のうち、[TO DO]と[username],[email]となっているところを任意の設定に変えてboard_engine直下で

$ bundle install

そして１番大事な親アプリケーションへ読み込ませる作業としてkinoko_engineのGemfileに

gem 'board_engine', path: 'board_engine'

を記載し、bundle installを実行。 そして親アプリケーションのrouteファイルへ

mount BoardEngine::Engine, at: '/board'

と記載し、マウント完了。ここで表示用のURLが設定できるので、 localhost:300x/boardが今回の確認用のURLとなる。 そして残るエンジン側のroute設定と表示確認のため、

$ cd board_engine

$ bundle exec rails g scaffold articles title body:text

にて一括で作成。 scaffoldをするとmigrationファイルも生成されるので、

$ cd ../

$ rake board_engine:install:migrations

にて親アプリケーションへコピー。（これでコピーできるの知らなかった）

そしてあとは親アプリケーションにてdb:migrateを実行し、/board/ariticleに遷移すると表示が確認できた！！

やってみて

とりあえず勉強用なので一旦ここまで。たしかに意外と読み込ませるまでは難しくなかった。 rails/info/routesでみてみると、

new_article_path GET /articles/new(.:format) blog_engine/articles#new

とか生成されててちょっと感動する。 調べてみると今回はgemで親アプリケーションへ読み込ませたが、gitからソースを読み込んで来る方が一般的らしい。

あとは詳細は

railsguides.jp

やっぱりこの辺を読んで勉強してみようと思う。 （これぐらい最初にやっておくとガイドもすんなり読めそうな気がする・・！）

※補足

ガイドを読んでみて、あーそうだったのか！というところが多かったので自分の学習のため追記。

  • --mountableオプション

    マウント可能かつ名前空間で分離されたエンジンを生成する場合に使用します。

→だから、scaffoldした時にblog_engine/articles#newという形で名前付きルートが設定されていたのかな。ちなみにappディレクトリツリーなんかもこの時生成される。 (多分、lib/blog_engine/engine.rbのisolate_namespaceメソッドが設定されるのではないだろうか）

デフォルトで名前空間が作られるあたり、やはり親アプリケーションとの親子関係が大前提なんだろうなぁと思う。

  • lib/blorgh/engine.rb

→config/application.rb と同等の役割をする。

  • isolate_namespaceメソッド

    エンジンのコントローラ/モデル/ルーティングなどが持つ固有の名前空間を、アプリケーション内部のコンポーネントが持つ類似の名前空間から分離する役目を担います。

→ようは名前衝突を避けるためということ。

ちょっとこれは本筋とはずれるけど、モデルのテーブルが名前空間化すると

モデルのテーブルも名前空間化され、単なるarticlesではなくblorgh_articlesになります。

ということらしい。

capistranoで自動デプロイをしてみる①

やりたいこと

  • さくらVPS + nginx + unicornでRailsアプリケーションの環境構築
  • capistranoとBitbucketのプライベートリポジトリを連携させ自動デプロイ
  • ではあるが、そもそもインフラ系初心者なのでSSHなどそのあたりにも触れてみたい。

さくらVPSを用意する

そもそもVPSって？ということで以下のサイトを読み込む。

knowledge.sakura.ad.jp

↑のサイトが鬼のようにわかりやすいが、要は1個の物理サーバがあり、そのホストOS上に仮想環境としてゲストOS+DB+webサーバを構築し、そこでいろいろゴニョゴニョやりましょうという話で、そこから簡単に利用状況に応じてスケールアップできるのがクラウド型、できないのがVPS型という住み分けと認識している。

VPS初操作

というわけで、早速手頃なサイズのプランを申し込み、以下のサイトをみながら初VPS操作。(やりたいことと書いておきながら、自分はインフラ初心者なので、ちょっとそのあたりの勉強もかねて関係ないかもしれないけどVPS周りを触ってみることにした。)

knowledge.sakura.ad.jp

デフォルトではLinuxのディストリビューションの１つであるCentOS6が入っているので、VPS側のコントロールパネルからCentOS7へアップデート。 その後、SSH接続でVPSヘアクセスする。（以後kinokoサーバとする）

SSHって？

Secure SHellと呼ばれる通信プロトコル。 リモート操作をしたい時の通信方法として、telnetと呼ばれるものがあるが、それをそのまま使うとパスワードなどのやり取りの際に中身が丸見えになってしまう。 それを防ぐために、telnetをもう少しセキュアにしたものがSSHになる。 そしてそのSSHにはパスワード認証式と公開鍵認証式がある。公開鍵認証には以下のサイトがわかりやすい。

qiita.com

動きとしては

  • ローカルで秘密鍵と公開鍵を作成
  • 公開鍵をサーバ側に持たせ、サーバ側で作成したユーザーと紐付ける。
  • ローカルでsshクライアント上からsshコマンドでログインを実行時に、サーバ側は保持した公開鍵にて、乱数により作成したハッシュ値を暗号化し、ローカルに返してくる
  • ローカルは秘密鍵を使ってそれを複合化し、取り出したハッシュ値を再度サーバへ渡す
  • それが正しい数値であれば認証完了

という仕組み。

ということで、まずは公開鍵認証ができるようにする。part1

とにもかくにも、rootユーザが仮に乗っ取られることがあるとサービスとしてやばい。 という観点から、まずはrootユーザの直接アクセスを禁止し、別のユーザからログイン後に$su - コマンドとかでroot権限に切り替えられるようにしておく必要がある。

sshクライアント（自分はmacなのでターミナル）を立ち上げ、

$ssh root@xxx.xxx.xxx

でパスワード入力後認証。root権限をもったユーザでログインできているので

$ adduser kinokochan

$ passwd kinokochan

でとりあえずkinokochanというユーザを生成。その後exitして再度sshにてkinokochanにログイン。

$ su-

でrootに変更後、

$ cd /etc/ssh

$ cp sshd_config sshd_config.old

でsshd_configというsshの設定ファイルを編集する下準備をしておく。 （cdコマンドで移動後、念のためバックアップとしてoldとリネームしてコピー）

さらにそこから

$ vim sshd_config

でvimを立ち上げ、

$ #PermitRootLogin yes

となっている箇所を、コメントアウトを外してyes→noに書き換え保存。

その後

$ systemctl restart sshd.service

でサーバ再起動。一旦exitし、ssh root@~でログインを試みてみると・・

Permission denied, please try again.

できた！！ 念のためkinokochanでログインをしても問題なく認証完了。とりあえずこれでroot乗っ取り危機は回避できました。

しばらくはこんな感じで長々とサーバ周りをいじる感じになりそう。

Read Me

■概要
保育業界の業務効率化webサービス「kinoko」を作ります！

 

■なぜ保育業界向けなのか？
・母も彼女も保育士なので、保育業界を身近に感じている
・保育業界の現場はまだまだ効率化できそうな余地がたくさんあると感じる
・保育士の労務環境改善がしたい
・待機児童などの問題解決につながりそう（社会貢献性が高い）
・少子高齢化に伴う政府施策の方針に合っている気がする
・テストを通じてエンジニアという仕事を身近な人に理解してもらえそう
・（ちょっとずれるけど）上記が自分の学習モチベーション向上に直結しそうだったから
・（ちょっとずれるけど）日々のアウトプットがしたい

 

■なぜkinokoなのか？
MariaDBやDebianとかと同じノリ

 

■なぜtakenokoなのか？
きのこと言えばたけのこだから

 

■環境
フレームワーク:Ruby on Rails
Ruby:v2.5.0
Rails:v5.0.0
データベース:MySQL
テストフレームワーク：Rspec
バージョン管理ツール:Bitbucket
デプロイ:capistrano
その他：Vue.Js,boot-strap

 

■仕様（随時追記）
まずはph1として以下の基本機能を実装予定。

・ログイン、サインアップ
→admin権限を持つユーザ（先生）のみ閲覧・操作できる部分があるようにする（adminフラグ）
・先生一覧、詳細
・園児一覧、詳細
・シフト管理機能
・日報機能

 

■アソシエーション
あとでER図を書いてみたいと思うが、
1対多、ないし1対1の関係性が基本になる予定
（先生A：日報、先生A:シフト、園児A：先生B、園児A:クラス など）

 

■運用
進捗や技術的な内容を中心にブログを更新していく。
個人的な心情などの更新もできればいいと思う。