为什么具有elasticsearch状态的docker镜像总是重新启动?

Raa*_*ady 1 elasticsearch docker

unbuntu 16.04,ram 1gb,在 aws 实例上

我必须运行旧的elasticsearch实例,所以我想使用elasticsearch 5.3.3版本的docker镜像。通过查看 stackoverflow 上多个具有相同标题的链接,我修改了基于 docker 映像的 elasticsearch 的安装,如下所示

sudo docker run -p 9200:9200 -p 9300:9300 -d -e "http.host=0.0.0.0" -e "transport.host=127.0.0.1" -e "xpack.security.enabled=false" --restart=unless-stopped --name careerassistant-elastic  docker.elastic.co/elasticsearch/elasticsearch:5.3.3
Run Code Online (Sandbox Code Playgroud)

安装完成,访问elasticsearch时出现问题,虽然我按照上面的命令进行了多次修改,但无法解决问题。当开启时

sudo docker ps
Run Code Online (Sandbox Code Playgroud)

状态仍然是 --> restarting(1) 48 秒前

当我检查 docker 的日志时,我无法理解任何内容,因为我对 docker 及其利用率很陌生

> docker logs --tail 50 --follow --timestamps careerassistant-elastic
Run Code Online (Sandbox Code Playgroud)

我得到以下输出

2020-05-04T09:36:00.552415247Z CmaTotal:              0 kB
2020-05-04T09:36:00.552418314Z CmaFree:               0 kB
2020-05-04T09:36:00.552421364Z HugePages_Total:       0
2020-05-04T09:36:00.552424343Z HugePages_Free:        0
2020-05-04T09:36:00.552427401Z HugePages_Rsvd:        0
2020-05-04T09:36:00.552430358Z HugePages_Surp:        0
2020-05-04T09:36:00.552433336Z Hugepagesize:       2048 kB
2020-05-04T09:36:00.552436334Z DirectMap4k:       67584 kB
2020-05-04T09:36:00.552439415Z DirectMap2M:      980992 kB
2020-05-04T09:36:00.552442390Z 
2020-05-04T09:36:00.552445460Z 
2020-05-04T09:36:00.552448777Z CPU:total 1 (initial active 1) (1 cores per cpu, 1 threads per core) family 6 model 63 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, avx, avx2, aes, clmul, erms, lzcnt, tsc, bmi1, bmi2
2020-05-04T09:36:00.552452312Z 
2020-05-04T09:36:00.552455227Z /proc/cpuinfo:
2020-05-04T09:36:00.552458471Z processor    : 0
2020-05-04T09:36:00.552461695Z vendor_id    : GenuineIntel
2020-05-04T09:36:00.552464872Z cpu family   : 6
2020-05-04T09:36:00.552467992Z model        : 63
2020-05-04T09:36:00.552471311Z model name   : Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz
2020-05-04T09:36:00.552474616Z stepping : 2
2020-05-04T09:36:00.552477715Z microcode    : 0x43
2020-05-04T09:36:00.552480781Z cpu MHz      : 2400.040
2020-05-04T09:36:00.552483934Z cache size   : 30720 KB
2020-05-04T09:36:00.552486978Z physical id  : 0
2020-05-04T09:36:00.552490023Z siblings : 1
2020-05-04T09:36:00.552493103Z core id      : 0
2020-05-04T09:36:00.552496146Z cpu cores    : 1
2020-05-04T09:36:00.552511390Z apicid       : 0
2020-05-04T09:36:00.552515457Z initial apicid   : 0
2020-05-04T09:36:00.552518523Z fpu      : yes
2020-05-04T09:36:00.552521677Z fpu_exception    : yes
2020-05-04T09:36:00.552524702Z cpuid level  : 13
2020-05-04T09:36:00.552527802Z wp       : yes
2020-05-04T09:36:00.552531691Z flags        : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx rdtscp lm constant_tsc rep_good nopl xtopology pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm invpcid_single kaiser fsgsbase bmi1 avx2 smep bmi2 erms invpcid xsaveopt
2020-05-04T09:36:00.552535638Z bugs     : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
2020-05-04T09:36:00.552538954Z bogomips : 4800.08
2020-05-04T09:36:00.552545171Z clflush size : 64
2020-05-04T09:36:00.552548419Z cache_alignment  : 64
2020-05-04T09:36:00.552551514Z address sizes    : 46 bits physical, 48 bits virtual
2020-05-04T09:36:00.552554916Z power management:
2020-05-04T09:36:00.552558030Z 
2020-05-04T09:36:00.552561090Z 
2020-05-04T09:36:00.552564141Z 
2020-05-04T09:36:00.552567135Z Memory: 4k page, physical 1014424k(76792k free), swap 0k(0k free)
2020-05-04T09:36:00.552570458Z 
2020-05-04T09:36:00.552573441Z vm_info: OpenJDK 64-Bit Server VM (25.131-b11) for linux-amd64 JRE (1.8.0_131-b11), built on Jun 16 2017 13:51:29 by "buildozer" with gcc 6.3.0
2020-05-04T09:36:00.552576947Z 
2020-05-04T09:36:00.552579894Z time: Mon May  4 09:36:00 2020
2020-05-04T09:36:00.552582956Z elapsed time: 0 seconds (0d 0h 0m 0s)
2020-05-04T09:36:00.552586052Z
Run Code Online (Sandbox Code Playgroud)

有人可以帮我找出 docker status 重新启动可能出现的问题吗?

Ami*_*wal 5

我在 AWS ec2 上运行我的 docker 容器t2.small,它有 2 GB RAM,因为t2.micro内存(1GB)不足以运行 Elasticsearch 容器,所以在您配置更多东西之前它应该也适合您。查看了您的日志,但我没有看到任何错误,因此如果没有您的 docker 文件就很难调试。

\n\n

下面是我的 docker-compose 文件,用于在 AWS t2.small 实例的 docker 容器中运行 Elasticsearch 7.6,如果它不适合您,请告诉我,我们很乐意为您提供进一步帮助。

\n\n
version: \'2.2\'\nservices:\n\xc2\xa0\xc2\xa0#Elasticsearch Docker Images: https://www.docker.elastic.co/\n\xc2\xa0\xc2\xa0elasticsearch:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0image: docker.elastic.co/elasticsearch/elasticsearch:7.6.0\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0container_name: elasticsearch\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0environment:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0- xpack.security.enabled=false\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0- "ES_JAVA_OPTS=-Xms512m -Xmx512m"\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0ulimits:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0memlock:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0soft: -1\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0hard: -1\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0nofile:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0soft: 65536\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0hard: 65536\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0cap_add:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0- IPC_LOCK\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0volumes:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0- elasticsearch-data:/usr/share/elasticsearch/data\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0ports:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0- 9200:9200\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0- 9300:9300\n\nvolumes:\n\xc2\xa0\xc2\xa0elasticsearch-data:\n\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0driver: local\n
Run Code Online (Sandbox Code Playgroud)\n\n

您可以使用命令运行它docker-compose up -d -e "discovery.type=single-node"。如果您遇到任何与内存相关的问题,请参考我的非生产模式下的 Elasticsearch docker 容器,以消除 vm.max_map_count=262144 要求答案vm.max_map_count=262144 requirement\n

\n