OpenShiftこんにちは。RailsのOpenShift上での開発について少しみていきたいと思います。自分がまさにそうなのですが、生のKubernetesを先に学んだあとにOpenShiftにはいると、結構違う部分もあってはじめ理解が難しい部分もあります。簡単な開発環境を作ってみて確認していきます。OpenShift初心者の方に少しでも参考になればと思います。minishiftを起動しようOpenShiftの環境は、一番用意しやすいであろうminishift(v1.33.0+ba29431)を使いました。minikubeのopenshift版と思っていただければ大丈夫です。ローカル端末の仮想マシンの上にOpenShiftが動く環境を立ち上げられるものです。本記事ではminishiftのインストールについては割愛しますが、下記を参考にインストールしてみてください。Latestocクライアントのバージョンは下記のとおりです。v1.11.0+d4caccRailsをOpenShift上で動作させるドキュメントを探していると、OpenShift上で動かせるRailsのアプリのサンプルを見つけました。ポイントを解説しながらみていきたいと思います。それがこの記事を書こうと思ったモチベ。new-appというただのPodやDeploymentだけでなくアプリケーションを作るためのコマンドが用意されています。実運用では利用されることは少ないかもしれませんが、今回のような開発環境のセットアップなどでは便利です。このコマンドは良くも悪くもいろんな動きをするので理解が難しい一面もあります。1つとして、OpenShiftなどで用意しているテンプレートからアプリケーションを実行することができます。どんなテンプレートがあるかは下記のように確認できます。Rails+PostgreSQLのセットになったもの、Jenkinsなどいくつかあります。9...テンプレートの実体は、kubernetesのマニフェストファイルでリソースの集合体です。OpenShiftにはTemplateというリソースがあります。マニフェストファイルの中のパラメータなどを変数化することが可能で、データベースなどのシークレット情報をパラメータ化して配布することなど可能です。access.redhat.com実際にテンプレートの中身は下記のようにして見ることができます。試しにpostgresqlのテンプレートをみてみますが、SecretやDeploymentConfig、Serviceのリソースが記載されているのがわかるかと思います。テンプレートを使って起動する際にどんなパラメータを指定できるかなど確認できるので便利です。今回は上で紹介したRailsのサンプルのアプリケーションのレポジトリがあったので、こちらでRailsアプリの方の起動を行っていきます。cloneして、テンプレートで起動してみます。この場は思考停止で実行してみます。app.実行後にpodの状態をみてみると、rails-postgresql-example-1-buildというbuildのpodが動いているのがわかります。こちらは後ほど説明しますが、いまRailsのアプリケーションのイメージを作っている最中です。17s起動が終わったあとに、routeを確認してアクセスしてみると。アプリケーションが動作しているのがわかります。routeはingressに相当するような概念で、外部からPodへのアクセスの経路を確保します。rails-postgresql-example-rails-dev.192.168.64.7.nip.ioと書いてあげればアクセスできますね。8080:8080のようにport-forwardを使ってアクセスしても問題ありません。None/articlesなどアクセスすれば、記事の登録もできDB連携もできていることが確認できます。ここまでやれば「なんか動いた!」という感じなわけですが、何が起きたのか少し追っていきたいと思います。作成されたリソースをみてみます。Noneなにやらいろいろと作成されていますが、取り上げてみていくのが、deploymentconfigとbuildconfigとimagestreamです。DeploymentConfigまずはDeploymentConfigをみていきます。KubernetesのDeploymentに該当するような機能で、trigger機能などがいくつかの機能が拡充されています。気になるポイントの1つ目としては、strategyのなかのpreです。db:migrateでテーブルのスキーマを作っていきますが、今回それを実行することなくアプリケーションの動作までいけていました。どこで実行されていたのか?というとここです。migrate-database.shが用意されていて、Podが新しくできるときにシェルを実行していました。次に気になるポイントは、triggersの部分です。この設定では、イメージの変更をトリガーに更新できる設定が入っています。後述するBuildConfigが新しいイメージを作成すると、それをトリガーにDeploymentConfigがPodを入れ替えてくれるわけです。ImageChangeBuildConfig続いてBuildConfig(bcと略せる)をみてみます。今回稼働させたRailsアプリケーションのコンテナイメージを作成するためのビルドの設定がこちらです。生のKubernetesではKubernetesとは別のプロセスとしてコンテナイメージを作成することが一般的かと思います。Image)という機能があり、開発者がコンテナイメージを作らなくても、書いたコードをOpenShiftで動かすためのワークロードが用意されています。そのビルドの設定がBuildConfigです。SOURCE_REPOSITORY_URLの中身をみてアプリケーションの種別(RubyなのかJavaなのか)を判別して、イメージをビルドしてくれました。herokuなどが近いでしょうか。(isと略せる)ですが、こちらも生のKubernetesにはないリソースです。コンテナイメージを抽象化した概念になります。特徴としては、コンテナイメージをプッシュした履歴が残る点です。今回、2回ビルドを行い、どちらもlatestタグでプッシュしましたが、イメージのハッシュ値で別々に管理されているのがわかります。そのため、今回のようにイメージのタグを特に考えずlatestのままでしたが、適切にPodの入れ替えが行われたということです。適当にアプリケーションを変更してgithubへpushします。データベースのスキーマも変更するような修正を入れたいと思います。scaffoldを使ってユーザモデルとコントローラを作ります。masterそれではこの変更をOpenShift上のRailsアプリケーションに反映させたいと思います。new-appで作られたBuildConfigなどはもちろんあとから実行が可能です。rails-postgresql-example-2-buildという2回目の実行のbuildコンテナが動いているのがわかります。<invalid>buildが終わるとImageStreamが更新され、それをトリガーにDeploymentConfigが新しいイメージでPodを入れ替えてくれました。http://rails-postgresql-example-rails-dev.192.168.64.7.nip.io/usersにアクセスするとユーザ情報を操作できる画面がでてきました。データベースのスキーマも無事に変更してくれています。裏では様々な動きが行われていて、奥深さを感じるものでした。OpenShiftを使った開発のフローや戦略がみえるものでもあるなあと感じます。今日見てきたところはほんのごく一部の基礎的なところではありますが、これからもOpenShiftを使ったアプリケーション開発について情報発信できたらと思います。HatでOpenShiftのサポートをしているid:nekopです。HatでOpenShiftのサポートをしているid:nekopです。各記事は著者の見解によるものでありその所属組織を代表する公式なものではありません。その内容については非公式見解を含みます。スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。