Linux

本番環境構築?Dockerで一発じゃん!!とか、思うやろ?

こんにちは。 PGで入社したつもりが、小さい会社ゆえ、

  • 開発
  • テスト
  • サーバー等の構築
  • 運用・保守

全部をやらせてもらえる筆者です。 (筆者的には短い期間に、スキルが身につくので願ったり叶ったりです⭐️)

今回筆者は、 インターネットに繋ぐことの出来ないサーバーに、Rails環境を構築しようとして、散々苦労したので、助かったポイント・苦労したポイントをメモとして残しておきたいと思います。

普通は、いくらインターネットに繋がないといっても、インターネットに繋がる環境で、環境を構築してから、お客様のところへ納品するのですが、様々な大人の事情で、既にインターネットから隔絶されているサーバーに一からCentoOs7でRails環境を構築する羽目になりました。

昨今インターネットを前提とした構築方法ばかりなので、他の人の役に立つかは分かりませんが、もう一度同じ目にあった時のために、殴り書きで書いたメモを元に、記載していきます。

前提条件

  • OSはCentOS7
  • 仮装サーバーはNG
  • コンテナもなし(dockerNG)😢
  • Rails5.2系
  • DBはpostgresql
  • 社のインターネット環境で、必要な物をダウンロードし、それを本番サーバーに持ち込む

各種rpmの準備

例えば、postgesql11-serverをインストールしようと思ったら、 普段なら、yum -y install postgresql11-serverで終わりの話ですが、今回はネットを使ったインストールは禁じられています。

よって、様々な依存関係を気にしながら、一つ一つ手でインストールする・・・

というのが昔からあるやり方だと思います。

ところが、postgresql11-serverの依存関係なんて言われても、何十・何百というパッケージを一つ一つ探しながら入れていたら、納期に間に合わない上、ストレスで禿げてしまいます。

そこで、非常〜〜〜に役に立ったのが、こちらのコマンド 「repotrack

yum install yum-utilsでインストールできます。

これで、お目当のパッケージをネットが使える環境でyum installしておけば、repotrack パッケージ名でそのパッケージと依存関係にある、パッケージ群を根こそぎダウンロードしてきてくれます。

これで、サービス軌道に必要な、rpm群を準備しておくことができます。

※とはいえ、当然根こそぎダウンロードしてくるので、既にインストール済みのものもダウンロードされるので、重複することは必至です。

Rails起動のためのgemを展開した状態で、本番環境へ移行する

この辺の記事を参考にさせていただきました。

インターネットが使える環境で bundle package --allを行い、それにより展開されるgem群を全てサーバー側に持って行くことになります。

サーバー側では bundle install --locak パスみたいな感じです。

とはいえ、筆者はgem nokogiriのインストールで何度もこけました。 内部的にあちこちで使われており、依存関係が非常にめんどくさかったです。

ソースコードと睨めっこしながら、必要っぽいライブラリをインストールしていきました。(-develなどのデベロップメントツール系とか)

bash_profileにパスを通したり

~/.bash_profileを開き、手間を省くため、環境変数を設定してきます。

例えば、postgresqlデフォルトで参照されるPGDATAの設定は、次のような感じで行います。

vi ~/.bash_profile

#以下は.bashprofileに追記(これでコマンドが楽に打てたり)
export PATH=~/home/path:$PATH
export PGDATA='/var/lib/postgres/11/data'

また、余談ですが、~/.bashrcにコマンドの別名をつけることも可能です。

#サーバーの起動系コマンドの別名を登録しておく
vi ~/.bashrc

alias db_start='postgresql-11.service'#pg_ctl startとか
alias app_start '~/service/rails s -b 0.0.0.0 -p 3000'

データベースの設定も忘れないように

initdbした時に作られるディレクトリ(データベースクラスタ)の中にある、pg_hba.confはDBに対して行われる接続要求に対して、許可・不許可・認証付き許可 などを設定するためのファイルです。

なので、


vi /var/lib/postgresql/11/data #パスは環境ごとに異なる

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust

↑こんな風に書かれています。

localがUnix認証を使った接続の許可、不許可であり、hostがTCP/IPを利用した通信の許可・不許可です。 これにより、一部の管理用端末からの接続を許可したり、アプリケーションサーバーからの通信を許可したりしましょう。

また、 postgres1l.confではユーザーからの接続を監視するlisten_addressesを設定したり、最大接続数、DBが起動するポート(デフォルは5432)を設定したりします。

DBの移行

DBを本番環境に移行する場合は、もしpgadmin4のような管理ツールが使えれば楽です。

開発用PC側でpgadmin4を開き、データベースのバックアップをしておき、サーバー側の感利用端末側で、リストアを行えば、すぐに完了します。

guiが難しければpg_dumpコマンドとpg_restpreコマンド/psqlコマンドでDBをバックアップ⇨リストアしましょう。

#社内開発 PC側(pg_dumpは/var/lib/posggres/11/dataのようにコマンドが通る場所で行う)
pg_dump データベース名 > 出力ファイル名
#-Fcなどのオプションで出力形式を選べる。今回はデフォの平文sql方式

#サーバー側
psql
\i さっき出力したファイル名
#これでsqlが実行され、dbの状態が再現される
#またpg_dumoでtar形式、カスタム形式で出力した場合は、pg_restoreコマンドでリストアする

まとめ

  • 依存関係はまともに立ち向かうのは危険。出来れば必要なものは根こそぎ開発用PCを利用して抜き出しておく
    • repotrack、gemのpackage化など
  • dbはすぐに移行できるように、出来ればバックアップ⇨リストアを実行して、試しておこう
  • postgresqlの知識は、oss silverの勉強をしてたら、スッと入ってきた。
    • 資格取得しながら、業務に必要な知識が手に入るとか最高なので、これからも勉強しようと思った