ЕР
ты же образ билдишь прямо на впс? не пробовал гарантированно рабочий образ с локальной машины перенести ?
образ со своим
dramatiq?Size: a a a
2020 July 02
ЕР
окей, сейчас протестирую, спасибо
ЕР
docker save ... | ssh docker load ...
ssh docker-compose up
ssh docker-compose up
история повторяется =(
GG
значит, дело не в образах, а в окружении
ЕР
очень странное дело
S
а вообще другие контейнеры запускаются на впс?
базовый рэббит, например
базовый рэббит, например
ЕР
а вообще другие контейнеры запускаются на впс?
базовый рэббит, например
базовый рэббит, например
да, другие крутятся нормально. сам контейнер с кроликом запускается без бубна, а вот контейнер с аппом, который подключается к кролику - не запускается, потому что не может подключится к кролику.
DG
@gecube не работает ;-(
Странно но вот какой output я получаю
RUN gulp build -m client --wlk ${IP_WHITELIST_CAPTCHA_KEY} --lk $LOGIN_CAPTCHA_KEY
При вот такой команде билда
docker build -t stil_image --build-arg VERSION=1.1.7-SNAPSHOT --build-arg IP_WHITELIST_CAPTCHA_KEY=foo --build-arg LOGIN_CAPTCHA_KEY=kuku .
и вот таком. Докерфайле:
ARG LOGIN_CAPTCHA_KEY
ARG IP_WHITELIST_CAPTCHA_KEY
ENV LOGIN_CAPTCHA_KEY=$LOGIN_CAPTCHA_KEY
ENV IP_WHITELIST_CAPTCHA_KEY=${IP_WHITELIST_CAPTCHA_KEY}
RUN npm install -g gulp@^4.0.0 bower verdaccio
RUN rm -f package-lock.json && \
RUN gulp build -m client --wlk ${IP_WHITELIST_CAPTCHA_KEY} --lk $LOGIN_CAPTCHA_KEY
Странно но вот какой output я получаю
RUN gulp build -m client --wlk ${IP_WHITELIST_CAPTCHA_KEY} --lk $LOGIN_CAPTCHA_KEY
При вот такой команде билда
docker build -t stil_image --build-arg VERSION=1.1.7-SNAPSHOT --build-arg IP_WHITELIST_CAPTCHA_KEY=foo --build-arg LOGIN_CAPTCHA_KEY=kuku .
и вот таком. Докерфайле:
ARG LOGIN_CAPTCHA_KEY
ARG IP_WHITELIST_CAPTCHA_KEY
ENV LOGIN_CAPTCHA_KEY=$LOGIN_CAPTCHA_KEY
ENV IP_WHITELIST_CAPTCHA_KEY=${IP_WHITELIST_CAPTCHA_KEY}
RUN npm install -g gulp@^4.0.0 bower verdaccio
RUN rm -f package-lock.json && \
RUN gulp build -m client --wlk ${IP_WHITELIST_CAPTCHA_KEY} --lk $LOGIN_CAPTCHA_KEY
НК
Всем привет. Никто не сталкивался с докером в режиме swarm с такой проблемой?
Проблема: при развертывании кластера elasticsearch если в yml файле у сервисов указаны healthcheck то кластер не собирается т.к. таски (контейнеры) не могут резолвить друг-друга по имени сервиса.
Пробовал заходить в контейнеры и делать пинги. Даже сам себя пинговать не может. Не резолвит имя.
Как только выкосил healthchecks все сразу собралось.
Причем не обязательно выкашивать все. Достаточно на нескольких сервисах.
Я не понял как это работает (
Версия докера: Server Version: 19.03.8
Хостовая система: CentOS 8.1.1911
Firewall: off
Selinux: disabled
Проблема: при развертывании кластера elasticsearch если в yml файле у сервисов указаны healthcheck то кластер не собирается т.к. таски (контейнеры) не могут резолвить друг-друга по имени сервиса.
Пробовал заходить в контейнеры и делать пинги. Даже сам себя пинговать не может. Не резолвит имя.
Как только выкосил healthchecks все сразу собралось.
Причем не обязательно выкашивать все. Достаточно на нескольких сервисах.
Я не понял как это работает (
Версия докера: Server Version: 19.03.8
Хостовая система: CentOS 8.1.1911
Firewall: off
Selinux: disabled
MG
В health check есть старт тайм пробовал повышать?
НК
да. было 45
увеличивал до 245
увеличивал до 245
НК
проблема в том что умирает именно dns резолвинг
НК
а пока он не оживет хэлфчек не пройдет
в итоге сервисы в бесконечном рестарте
в итоге сервисы в бесконечном рестарте
НК
в параллельном чатике мне один намекнул что это многолетняя бага докера
GG
Всем привет. Никто не сталкивался с докером в режиме swarm с такой проблемой?
Проблема: при развертывании кластера elasticsearch если в yml файле у сервисов указаны healthcheck то кластер не собирается т.к. таски (контейнеры) не могут резолвить друг-друга по имени сервиса.
Пробовал заходить в контейнеры и делать пинги. Даже сам себя пинговать не может. Не резолвит имя.
Как только выкосил healthchecks все сразу собралось.
Причем не обязательно выкашивать все. Достаточно на нескольких сервисах.
Я не понял как это работает (
Версия докера: Server Version: 19.03.8
Хостовая система: CentOS 8.1.1911
Firewall: off
Selinux: disabled
Проблема: при развертывании кластера elasticsearch если в yml файле у сервисов указаны healthcheck то кластер не собирается т.к. таски (контейнеры) не могут резолвить друг-друга по имени сервиса.
Пробовал заходить в контейнеры и делать пинги. Даже сам себя пинговать не может. Не резолвит имя.
Как только выкосил healthchecks все сразу собралось.
Причем не обязательно выкашивать все. Достаточно на нескольких сервисах.
Я не понял как это работает (
Версия докера: Server Version: 19.03.8
Хостовая система: CentOS 8.1.1911
Firewall: off
Selinux: disabled
Сварм, эластик? Я точно на той планете?
MG
проблема в том что умирает именно dns резолвинг
А днс по task. Service name или как?
НК
днс по service name
НК
master1:
image: docker.elastic.co/elasticsearch/elasticsearch:7.8.0
environment:
- node.name=master1
- node.master=true
- node.data=false
- ES_JAVA_OPTS=-Xms4g -Xmx4g
- cluster.name=t-cluster
- network.host=0.0.0.0
- discovery.seed_hosts=master1,master2,master3
- cluster.initial_master_nodes=master1,master2,master3
networks:
- esnet
volumes:
- esmaster1:/usr/share/elasticsearch/data
deploy:
placement:
constraints: [ node.name == node-1 ]
endpoint_mode: dnsrr
mode: "replicated"
replicas: 1
resources:
limits:
memory: 5G
master2:
image: docker.elastic.co/elasticsearch/elasticsearch:7.8.0
environment:
- node.name=master2
- node.master=true
- node.data=false
- ES_JAVA_OPTS=-Xms4g -Xmx4g
- cluster.name=t-cluster
- network.host=0.0.0.0
- discovery.seed_hosts=master1,master2,master3
- cluster.initial_master_nodes=master1,master2,master3
networks:
- esnet
volumes:
- esmaster2:/usr/share/elasticsearch/data
deploy:
placement:
constraints: [ node.name == node-2 ]
endpoint_mode: dnsrr
mode: "replicated"
replicas: 1
resources:
limits:
memory: 5G
master3:
image: docker.elastic.co/elasticsearch/elasticsearch:7.8.0
environment:
- node.name=master3
- node.master=true
- node.data=false
- ES_JAVA_OPTS=-Xms4g -Xmx4g
- cluster.name=t-cluster
- network.host=0.0.0.0
- discovery.seed_hosts=master1,master2,master3
- cluster.initial_master_nodes=master1,master2,master3
networks:
- esnet
volumes:
- esmaster3:/usr/share/elasticsearch/data
deploy:
placement:
constraints: [ node.name == node-3 ]
endpoint_mode: dnsrr
mode: "replicated"
replicas: 1
resources:
limits:
memory: 5G
НК
вот так оно собирается