Ага, понял, спасибо

но неужели критерий скорости запуска чего-то там так важен для облаков? какая разница , казалось бы, за 2 минуты оно запустится или за 10?

Ну вообще-то между 2 минуты и 10 огромная разница

А лучше чтобы запускался не 2 минуты а 5 секунд.

А когда контейнеров 50000, как любят показывать все подряд - то разница вот прям очень видна

но неужели критерий скорости запуска чего-то там так важен для облаков? какая разница , казалось бы, за 2 минуты оно запустится или за 10?

ну разница между 0.36 секунд и 2 секунды и правда не очень заметна.

Вообще, странное сравнение. Это как сравнивать Apache Benchmark и Yandex Tank по скорости запуска. Swarm и Kubernetes - они же о разном. Если swarm обрастёт всем тем, что есть в k8s, то тоже станет слоупоком.

Интересно, как именно сравнивали. Я слепой или там реально нет этих подробностей?

кто поднимал редмайн в докере, есть готовые машины?

и как оно с jruby

:D

вог даже официальное репо есть https://hub.docker.com/_/redmine/

Ну вообще-то между 2 минуты и 10 огромная разница

нет родствкенника с именем сергей?

Господа, я весь в сомнениях. Вот есть у меня контейнер, и я хочу, чтобы он запускался при старте системы. Пихать ли его запуск в системд юнит или запускать с —restart=unless-stoped -d? Разницы в обоих случаях не нашел, как лучше то?

имхо - с -д лучше ;)

блин я последний час навверное потратил на то чтоб запускать и так и так. взял первый попавшийся контейнер, в моем случае Rethinkdb —restart=unless-stoped легко повторяется через Restart=on=failure -d по сути просто чтоб запустить контейнер в фоне. системд его тоже не в твоей консоли запускает

в самой документации докера написано: As of Docker 1.2, restart policies are the built-in Docker mechanism for restarting containers when they exit. If set, restart policies will be used when the Docker daemon starts up, as typically happens after a system boot. Restart policies will ensure that linked containers are started in the correct order. If restart policies don’t suit your needs (i.e., you have non-Docker processes that depend on Docker containers), you can use a process manager like upstart, systemd or supervisor instead.

то бишь они рекомендуют свой --restart

Просто получается тогда что часть управления контейнерами переносится куда то еще

но вот если я запущу контейнер с docker run --restart=unless-stoped а потом сделаю docker stop и после этого рестартану систему, он ведь не запустится?

Угу

значит нужен велосипед, который будет контроллировать это

всеравно лишнее звено

И это ожидаемо - ты его остановил

нууу... если это десктопное приложение то да. а если это nginx. я же хочу чтоб он запускался на старте системы

где все вообще? :) вдвоем неинтересно обсуждать, твои аргументы я уже знаю

А ты поменно попингуй народ :)

эх я не админ

запинил бы сообщение

всеб ругались :) но увидели

Поэтому и не админ :)))

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

но как то контроллировать запустился контейнер на старте придется

Так системд умеет же просто запускать и не следить дальше

ну можно так да

Restart always, никогда небыло проблем

Не о том речь

А о чем?

использвать системд для контроля докер контейнеров или нет

Зачем? Что бы он поднимал контейнер если ты забыл запустить его?

Угу. Вместо йодомарина - систеидимарин

Все херня, если ты запускаешь контейнер пусть докер за этим следит

А как же ФСБ?

Если что-то не работает то это по мониторингу задача

А кстати удобно, я только понял - всегда можно позвонить будет в ФСБ и спросить работает ли сервер. Они ж все нынче мониторят

Если инета нет например

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

ребята кто-либо делал мультитрединг когда воркеры - каждый в отдельном докер-контейнере на Mesos+Marathon? вообще рабочий вариант?

если делали, знаете пхп и интересует работа - стучитесь в личку :)

то есть вот так :) пхп + мезос?)

да, почему нет? )

использвать системд для контроля докер контейнеров или нет

Я бы лучше системд использовал. Там можно следить и поднимать контейнер, плюс запускать при старте системы, и еще доп. логику накрутить.

Coreos рекомендуют системд для прода

использвать системд для контроля докер контейнеров или нет

да

это позволит более прозрачно потом мигрировать на Rkt

причина :))

тоесть у меня over 200 контейнеров и я должен под каждый делать настройку в systemd ?

а почему бы и нет?

это можно автоматизировать

почти все запускаются через compose... куда там тулить systemd?

про compose не знаю, я стараюсь не использовать Docker

точнее

только запуск контейнеров и всё

всё что можно не делать через экосистему Docker, а делать как-то иначе - я делаю как-то иначе

вон из чата ?

ERROR: S client not available

в будущем, когда допилят Rkt, я просто подредактирую те *.service файлы и заменю там docker на rkt

тоесть у меня over 200 контейнеров и я должен под каждый делать настройку в systemd ?

речь не о 200 контейнеров. так дохуя я засуну в swarm или там еще куда. речь об одном контейнере. например я хочу registry. один, вне кластера

гыгы, ну пока докер рулит

но как только будет нормальная замена в виде Rkt - сразу же свалю

ну даже registry у меня не сам запускается, поэтому в compose

ну а compose у тебя как запускается?

и я могу как угодно рестартить сервер и знаю что docker сам все поднимет... compose это вобще статическая херь, ее не нужно запускать

ну кто то должен сделать docker-compose up

а я вот не могу рестартить - у меня разделы зашифрованы

или как там

и всё равно пароль к диску вводить надо при старте

ну кто то должен сделать docker-compose up

это делается один раз при деплое приложения через ansible модуль servises

и всё равно пароль к диску вводить надо при старте

Вопрос вообще не об этом. причем тут шифрованные диски и ркт?

Вопрос вообще не об этом. причем тут шифрованные диски и ркт?

вопроса вообще то небыло

Господа, я весь в сомнениях. Вот есть у меня контейнер, и я хочу, чтобы он запускался при старте системы. Пихать ли его запуск в системд юнит или запускать с —restart=unless-stoped -d? Разницы в обоих случаях не нашел, как лучше то?

тут про то, что докер пытается собой заменить всё остальное, но как бы не с systemd докеру тягаться

был

тут про то, что докер пытается собой заменить всё остальное, но как бы не с systemd докеру тягаться

ну контейнер раньше докера ты все равно не запустишь

да, в systemd можно разрулить зависимости

это делается один раз при деплое приложения через ansible модуль servises

чет не могу нагуглить

но когда у тебя еще плагины к докеру, то только сам докер знает когда что ему запускать

чет не могу нагуглить

restart: always что гуглить то?

просто в одном случае у тебя докер будет следить и поднимать контейнер

не могу нагуглить ansible модуль services

а в другом случае systemd

если он упал

не могу нагуглить ansible модуль services

https://docs.ansible.com/ansible/docker_service_module.html

ну и вот почему хотеть все эти задачи вешать на докер - я не понимаю

https://docs.ansible.com/ansible/docker_service_module.html

сенькую

ну и вот почему хотеть все эти задачи вешать на докер - я не понимаю

потому что есть одна экосистема, которая сама может (ДОЛЖНА) это делать

юникс вэй - это когда есть много разных утилит и каждая хорошо выполняет свою маленькую задачу

вот я например хочу что бы контейнер был запущен в кластере, тут systemd уже никак не поможет