# 本番環境

> Source: https://www.ymotongpoo.com/works/adopting-erlang-ja/production/


Erlang/OTPはたしかに独自の言語かつランタイムですが、支持者が言うほど他と懸け離れているわけではありません。ここでは、デプロイ用の成果物を作り、他のサービスと同じ環境で運用する方法を見ていきます。具体的には、リリースを作成し、そのDockerイメージを作り、Kubernetesクラスタにデプロイします。

フォーラムや技術系ニュースサイトのコメント欄でよく見かける主張に、「OTPがあればKubernetesは要らない」、あるいはその逆で「Kubernetesを使えばOTPは要らない」というものがあります。しかしErlangがKubernetesを置き換えるわけでも、KubernetesがErlangを置き換えるわけでもありません。もしErlangシステムがsupervisorツリーを持つことで他のランタイムと同様の監視や再起動を必要としないのであれば、[heart](http://erlang.org/doc/man/heart.html)のようなツールは存在しないはずです。同様に、`heart`でプログラム全体を再起動すれば十分なのであれば、supervisorツリーは不要だったはずです。

[Kubernetes](https://kubernetes.io/)は、コンテナとして動かすプログラムを物理・仮想マシン上に効率よく詰め込むスケジューラを提供します。コンテナを使うことで、依存関係(たとえばErlangリリースにおけるOpenSSLなど)を1つのイメージにまとめてデプロイを簡単にし、あるマシン上で動く複数のサービス間で依存関係が衝突しないよう分離もできます。さらに、言語やランタイムが何であれ、本番環境内の各サービスに対するデプロイと管理を一貫させられます。Erlangサービスを一般的な監視・トレーシングの仕組みと統合すれば、同僚たちに「扱いづらい変わり者」として煙たがられることもなくなるでしょう。

とはいえ、コンテナやKubernetesがあらゆる場合に適しているわけではありません。ホスティングされたソリューションを選べない場合や、製品が組み込み機器である場合などは、Kubernetesはオーバースペックになりえます。

- [リリース](/works/adopting-erlang-ja/production/releases/)
- [Docker](/works/adopting-erlang-ja/production/docker/)
- [Kubernetes](/works/adopting-erlang-ja/production/kubernetes/)
- [オブザーバビリティ](/works/adopting-erlang-ja/production/operations/)