MongoDb в Azure экземпляре контейнера выходит из строя через некоторое время

Question

У меня mongoDB работает в Azure экземпляре контейнера. БД работает постоянно, и все в порядке, но бывает 2 раза, когда контейнер переходит в состояние Failed. Состояние отказа наступило в течение одного месяца. Это мой Dockefile:

FROM ubuntu:xenial

# Update the repository sources list
RUN apt-get update && apt-get install -y wget gnupg apt-transport-https ca-certificates vim 

#Import GPG Key from https://www.mongodb.org/static/pgp/server-4.2.asc:
RUN wget -qO - https://www.mongodb.org/static/pgp/server-4.2.asc | apt-key add -

#Create a list file /etc/apt/sources.list.d/mongodb-org-4.2.list for MongoDB
RUN echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/4.2 multiverse" |  tee /etc/apt/sources.list.d/mongodb-org-4.2.list

#Install the latest stable version of MongoDB
RUN apt-get update && apt-get install -y mongodb-org 
RUN mkdir -p /data/db

# Expose the default port
EXPOSE 27017

CMD ["--port 27017", "--smallfiles"]

# Set default container command and overwrite default address 127.0.0.1 with 0.0.0.0
ENTRYPOINT usr/bin/mongod --bind_ip 0.0.0.0

Это трассировка журнала от mongoDb:

ing data from the last clean checkpoint.
2020-07-29T12:27:25.654+0000 I  STORAGE  [initandlisten] wiredtiger_open config: create,cache_size=256M,cache_overflow=(file_max=0M),session_max=33000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000,close_scan_interval=10,close_handle_minimum=250),statistics_log=(wait=0),verbose=[recovery_progress,checkpoint_progress],
2020-07-29T12:27:28.207+0000 I  STORAGE  [initandlisten] WiredTiger message [1596025648:207010][7:0x7fdd6c925b40], txn-recover: Recovering log 81 through 82
2020-07-29T12:27:29.486+0000 I  STORAGE  [initandlisten] WiredTiger message [1596025649:486068][7:0x7fdd6c925b40], txn-recover: Recovering log 82 through 82
2020-07-29T12:27:30.769+0000 I  STORAGE  [initandlisten] WiredTiger message [1596025650:769360][7:0x7fdd6c925b40], txn-recover: Main recovery loop: starting at 81/19968 to 82/256
2020-07-29T12:27:32.214+0000 I  STORAGE  [initandlisten] WiredTiger message [1596025652:214855][7:0x7fdd6c925b40], txn-recover: Recovering log 81 through 82
2020-07-29T12:27:33.546+0000 I  STORAGE  [initandlisten] WiredTiger message [1596025653:546929][7:0x7fdd6c925b40], txn-recover: Recovering log 82 through 82
2020-07-29T12:27:33.599+0000 I  STORAGE  [initandlisten] WiredTiger message [1596025653:599411][7:0x7fdd6c925b40], txn-recover: Set global recovery timestamp: (0, 0)
2020-07-29T12:27:33.833+0000 I  RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2020-07-29T12:27:34.222+0000 I  STORAGE  [initandlisten] Timestamp monitor starting
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten]
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten]
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten]
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten] **        We suggest setting it to 'never'
2020-07-29T12:27:34.376+0000 I  CONTROL  [initandlisten]
2020-07-29T12:27:34.567+0000 I  SHARDING [initandlisten] Marking collection local.system.replset as collection version: <unsharded>
2020-07-29T12:27:35.064+0000 I  STORAGE  [initandlisten] Flow Control is enabled on this deployment.
2020-07-29T12:27:35.064+0000 I  SHARDING [initandlisten] Marking collection admin.system.roles as collection version: <unsharded>
2020-07-29T12:27:35.064+0000 I  SHARDING [initandlisten] Marking collection admin.system.version as collection version: <unsharded>
2020-07-29T12:27:35.350+0000 I  SHARDING [initandlisten] Marking collection local.startup_log as collection version: <unsharded>
2020-07-29T12:27:35.351+0000 I  FTDC     [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2020-07-29T12:27:35.353+0000 I  SHARDING [LogicalSessionCacheRefresh] Marking collection config.system.sessions as collection version: <unsharded>
2020-07-29T12:27:35.353+0000 I  SHARDING [LogicalSessionCacheReap] Marking collection config.transactions as collection version: <unsharded>
2020-07-29T12:27:35.353+0000 I  NETWORK  [listener] Listening on /tmp/mongodb-27017.sock
2020-07-29T12:27:35.353+0000 I  NETWORK  [listener] Listening on 0.0.0.0
2020-07-29T12:27:35.353+0000 I  NETWORK  [listener] waiting for connections on port 27017
2020-07-29T12:27:36.167+0000 I  FTDC     [ftdc] Unclean full-time diagnostic data capture shutdown detected, found interim file, some metrics may have been lost. OK
2020-07-29T12:27:36.865+0000 I  SHARDING [ftdc] Marking collection local.oplog.rs as collection version: <unsharded>

1. Как я могу это исправить?
2. Насколько хорошая идея в любом случае иметь производственную БД в контейнере?

Спасибо.

Answer 1

Я не вижу проблем в dockerfile, которым вы здесь поделились. Однако, если у вас есть какие-либо сомнения относительно dockerfile mon go, вы можете использовать официальный dockerfile mongodb (https://github.com/docker-library/mongo).

Для фактического устранения проблемы вам понадобится чтобы понять, что именно произошло с контейнерами, и потребуются журналы для этого.