Misskeyのコンテナ化と共に
苦労したものとして挙がるのが、Elasticsearchのコンテナ化。
私の場合は、昔覚えた内容などで何とかYAMLを書いてリソース化するのだけど、どーしてもすぐにCrashBackOffになり、再起動をひたすら繰り返す。さて困った。
やっぱLog見ないとだめね・・
というわけで、ログの見方なんですけれども
■一つ目
{"type": "server", "timestamp": "2019-11-04T03:58:10,147Z", "level": "INFO", "component": "o.e.b.BootstrapChecks", "cluster.name": "misskey-cluster", "node.name": "elsearch-sv-bcd4d59bd-pxkws",
"message": "bound or publishing to a non-loopback address, enforcing bootstrap checks" }
■二つ目
ERROR: [1] bootstrap checks failed
[1]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured
■三つ目
{"type": "server", "timestamp": "2019-11-04T03:58:10,172Z", "level": "INFO", "component": "o.e.n.Node", "cluster.name": "misskey-cluster", "node.name": "elsearch-sv-bcd4d59bd-pxkws", "message": "stopping ..." }
JSON形式で応答は帰ってきまして、その中で「message」を参照することで実態のログメッセージが出ます。巷のブログだと、よく「bootstrap checksをバイパスすれば・・・！」的な話が聞こえ、それを真に受けて今回私も設定しているわけなんですが、このメッセージを見る限りはどーやらループバックでサービスを受け付ける構成にしてない場合、否が応にもbootstrap checkが行われるっぽいっすね。
今回の場合
今回の場合、答えとしてはこちらにありました。
[1]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured
Discovery設定が行われていない。discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodesのいずれかを最低限一つは設定しろとのことのようです。よって、そのあたりをYAMLの中に書き込む必要があります。
設定箇所
YAMLで作る際のenvに以下の記述が必要です。
- name: discovery.type
value: "single-node"
クラスタ関連のパラメータは今回使用してません。今回はシングルノード構成であるためです。
そこで、discovery.typeに対して「single-node」を定義する必要があるようです。この設定を行ってデプロイしたところ、正常にPodが作成されました。
当方の設定例
Deployment設定のみ例示しておきます。あくまで私の環境のやつなので、適宜読み替えてくださいませ。
apiVersion: apps/v1
kind: Deployment
metadata:
name: elsearch-sv
spec:
replicas: 1
selector:
matchLabels:
app: elsearch
template:
metadata:
labels:
app: elsearch
spec:
containers:
- name: elsearch-sv
image: elasticsearch:7.4.2
imagePullPolicy: "IfNotPresent"
env:
- name: cluster.name
value: misskey-cluster
- name: bootstrap.memory_lock
value: "false"
- name: bootstrap.system_call_filter
value: "false"
- name: discovery.type
value: "single-node"
- name: cluster.routing.allocation.disk.threshold_enabled
value: "false"
- name: ES_JAVA_OPTS
value: -Xms1536m -Xmx1536m
- name: http.host
value: 0.0.0.0
- name: transport.host
value: 0.0.0.0
- name: path.repo
value: "/usr/share/elasticsearch/data/backups/backup1"
resources:
limits:
memory: 2560Mi
ports:
- containerPort: 9200
name: http-port
protocol: TCP
- containerPort: 9300
name: transport
protocol: TCP
volumeMounts:
- mountPath: /usr/share/elasticsearch/data
name: elsearch-sv
volumes:
- name: elsearch-sv
persistentVolumeClaim:
claimName: nfs-elsearch-pvc01
実際にはJVM Heapサイズの+256MBぐらいが消費されてた感じですので、Limitsはもう少し絞ってよいのかもしれないです。あと、ConfigMapなどでEnv設定は整理しとくと運用管理しやすいのかなーとも思いました。
また、今どきはElastic社がこんなの出してるようで・・・
これを実用環境とかでは使ったほうが良いのかもしれません。実装の仕組みはかなり変わる（そもそもAPIがElastic社独自を使う感じになる）のと、ユーザ認証が初期状態だと強制される構成でしたので、ちゃんと調べて実装したほうがいいかな？という気がします。
using WordPress and
Comments are closed