А чем Rkt в своём конфиге отличается от Dockerfile?

Можешь показать пример?)

из конфигов у меня там только авторизация на докерхабе и всё

просто json

Какой нибудь из туториала?

Что нибудь

вот пример

#ExecStart=/usr/bin/docker run --name byvshie -p 17100:8001 -v byvshie-media:/usr/src/app/www/htdocs/media -e ENV=production -e DATABASE_HOST=172.17.0.1 -e DATABASE_PORT=48002 --cpuset-cpus="4,5" lorddaedra/entropia:byvshie-latest ExecStart=/usr/bin/taskset -c 4,5 /usr/bin/rkt --insecure-options=image run --port=8001-tcp:17100 --volume byvshie-media,kind=host,source=/var/lib/docker/volumes/byvshie-media/_data --mount volume=byvshie-media,target=/usr/src/app/www/htdocs/media --set-env=ENV=production --set-env=DATABASE_HOST=172.17.0.1 --set-env=DATABASE_PORT=17102 docker://lorddaedra/entropia:byvshie-latest

вверху как было с докером, внизу как стало с Rkt'ом

то есть те же параметры, просто немного иначе запихиваются в командную строчку

ну, вот из наблюдений, при указании имени volume'а нельзя использовать точки, я их заменил на дефисы

byvshie-media нельзя было бы написать как byvshie.media

а в докере можно

ну ещё нет встроенной возможности ограничить ядра, это через taskset

при конвертации из докера он порты называет как 8001-tcp если там был порт 8001

если сам собираешь через acbuild - то, конечно, любое название можно дать

Странно)

у меня сейчас все контейнеры запущены путём конвертации докер-образа в .aci

то есть они все собирались через Dockerfile'ы

апдейты в кореос - бомба

поменял канал - пришел апдейт, сделал рестарт

свежий докер)

глубоко не копал, но контейнеры с uwsgi, nginx, postgresql запускаются ок

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

апдейты в кореос - бомба

как с управляемостью ?

сервисы при этом разъехались ?

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

надо будет сервисов поднять и посмотреть как они разъезжаться будут, да

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

ну, я не говорил, что виноват php, но с ним всегда какие-то проблемы

сейчас я просто пока оставил этот контейнер на докере

мне интересно, что там с сеткой

кто как делает

варианты разные есть

мне бы как попроще

Марину в баню

Превентивно

А кто как настраивает хосты уже после сетапа? ansible?

или cloud-config правите и запускаете coreos-cloudinit?

terraform?

@lorddaedra я встречал от вас мнене что systemd прекрасен и вы его фанат

и что это единственный вариант для 2016 года.

но скажите же мне чем его мониторить ?

где информация метрического характера ?

сколько раз перезаускалась служба ? сколько времени работал скрипт ?

где вот это все ?

@lorddaedra я встречал от вас мнене что systemd прекрасен и вы его фанат

насчёт фанатизма - systemd лучше, чем upstart и sysvinit

ок. лучше. пусть.

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

управляется через systemctl, есть стандартные команды start, stop, status, restart

можно разбить проект на разные сервисы, объединить их в 1 .target и поставить зависимости, определяющие порядок запуска

Саша, ну мониторинг же?

например, чтобы СУБД всегда запускалась раньше, чем nginx

сколько раз падала служба ?

точнее не так

сколько раз системд ее перезапустил ?

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

ну и ещё есть watchdog

WatchdogSec= Configures the watchdog timeout for a service. The watchdog is activated when the start-up is completed. The service must call sd_notify(3) regularly with "WATCHDOG=1" (i.e. the "keep-alive ping"). If the time between two such calls is larger than the configured time, then the service is placed in a failed state and it will be terminated with SIGABRT. By setting Restart= to on-failure, on-watchdog, on-abnormal or always, the service will be automatically restarted. The time configured here will be passed to the executed service process in the WATCHDOG_USEC= environment variable. This allows daemons to automatically enable the keep-alive pinging logic if watchdog support is enabled for the service. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main. Defaults to 0, which disables this feature. The service can check whether the service manager expects watchdog keep-alive notifications. See sd_watchdog_enabled(3) for details. sd_event_set_watchdog(3) may be used to enable automatic watchdog notification support.

Саша, ну простой вопрос. Сколько раз перезапустил то ?

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

просто сторонний SaaS это мониторит и отправляет смски если что-то не работает

но, наверное, как-то можно вытащить эти данные, если нужно

я просто не углублялся в эти вещи

ну тоесть сисемд в году посвященном мониторингу и управляемости сервисов, когда все с ума сходят по метриам ну умеет две важные вещи. 1. рассказывать как у него идут дела 2. http api. docker всё это делает. но он плохой. так ?

а вот у CoreOS как раз-таки есть какой-то сервис для управления systemd через http api или как-то так

в CoreOS есть Fleet, это как глобальный systemd уровня кластера

там идёт взаимодействия с systemd каждой ноды

я бы посоветовал покопать его и посмотреть, как они там это сделали технически

предполагаю, что там как раз и отыщется этот http api

или какой-то его близкий аналог

> docker всё это делает. но он плохой. так ? докер хороший стартап)

просто лично мне он не очень нравится, каждому своё

докер инструмент который реализует функционал.

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

про мониторинг systemd - не знаю, насколько красивое решение, но можно опрашивать status и там будет Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago

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

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

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

про systemd - я не считаю его идеальным, но когда вопрос стоит, что лучше, systemd vs docker или systemd vs upstart или systemd vs sysv, то я бы предпочёл systemd

а в докере можно будет скоро.

ну, я не хейтер докера)