| 1.1, Аноним (1), 18:35, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –21 +/– |
обладатели musl'овского войд-линукса должны быть рады релизу. хмм... хотя таких будет полтора человека.
| | |
| |
| 2.4, Ыыых (?), 19:08, 20/10/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
Alpine тоже на musl'ях)) и намного популярнее воЁда)
| | |
| |
| |
| 4.12, Аноним (12), 21:46, 20/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Не поверите - чтобы быть запущенным первым процессом в контейнере и дальше выполнить то, что нужно автору контейнера.
| | |
| |
| 5.26, abu (?), 12:30, 21/10/2018 [^] [^^] [^^^] [ответить]
| +2 +/– | |
(не туда нажал и по ошибке плюсанул - жалею)
Разве идеология докера не подразумевает, что автор контейнера должен понимать и запускать один сервис в одном контейнере? Авторы, блин.
=
It is generally recommended that you separate areas of concern by using one service per container.
=
https://docs.docker.com/config/containers/multi-service_container/
Суете что попало в эти докеры-контейнеры. А они не о том.
| | |
| |
| 6.33, username (??), 08:31, 23/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Дело тут в чем.
Практического вреда от запихивания "всего" в контейнер нет если это сделано разумно, поэтому обычно делают как удобно.
Лично я предпочитаю разбивать по логическим группам а не воротить 3 контейнера на 1 приложение. Вреда от этого грубо говоря никакого если у тебя веб сервер например сам себе инит.
Ну а фантазии идеологов это хорошо, только реальность зачастую не та.
| | |
| 6.35, freehck (ok), 00:17, 26/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
 > Разве идеология докера не подразумевает, что автор контейнера должен понимать и запускать один сервис в одном контейнере? Авторы, блин.
Тут нет противоречия. Запускать ты можешь что угодно. Главное, чтобы в конце был exec нужного сервиса. Именно так и клепают энтрипоинты, между прочим.
К тому же, ничто не мешает сделать основным процессом супервайзер (например djb's supervise), и таким образом обеспечить параллельную работу в контейнере нескольких демонов. Можно придумать юзкейсы, хотя лучше конечно так не делать.
| | |
|
| 5.27, fske (?), 15:15, 21/10/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
Не поверим. Рукожопые деблоиды не могут даже документацию прочитать, и понять, что контейнер - не виртуалка, и нех туда иниты, апстарты, системды и прочую подобную дрянь пихать
| | |
| |
| 6.29, Аноним (-), 19:01, 21/10/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
Контейнер, конечно, не виртуалка, но некоторые вещи делаемые штуками типа systemd неплохо смотрятся и в контейнере. Типа мониторинга живости процесса, например. А докер что, ему в чистом виде глубоко наплевать если критичный процесс внутрях возьмет и повиснет.
| | |
| |
| 7.31, Хипстер (?), 20:51, 21/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
И действительно, утилиты типа monit для нас неведомы. Только системд, только сму^W хардкор
| | |
| 7.34, пох (?), 12:18, 25/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Контейнер, конечно, не виртуалка, но некоторые вещи делаемые штуками типа systemd неплохо
> смотрятся и в контейнере.
вся суть отличия контейнеров от виртуалок - что эти вещи НЕЗАЧЕМ засовывать в контейнер.
Он прекрасно мог бы мониториться тем самым systemd, находящимся _снаружи_.
На практике - это одна из многих вещей, недоделанных стадом макак, поскакавших, задрав обоcpaнные хвосты, дальше во всякие поебeнeтесы, бросив обгрызанного недоделка на пол-дороге.
в результате у нас есть два недоделанных расширения к systemd, ни одно нормально не работает, автодетект в самом системд запуска внутри контейнера (после срабатывания весь полезный функционал отключается нахрен) и куча контейнеров, переизобретающих операционную систему с нуля - начиная от умения правильно завершиться по docker stop, аккуратно завершив дочерние процессы, а не висеть минуту с последующим kill -9 на кого попало, заканчивая периодическими процессами, которые таки надо бы иногда запускать, но толком нечем - посмотрите, к примеру, в docker registry, образцовый пример пионерского упорства в преодолении самим себе созданных трудностей.
а нормально рабоают jail'ы в freebsd. Как и двадцать лет назад. Но есть ньюанс, да - в них нельзя docker run какая-то-хрень-прямо-с-хаба
| | |
|
|
|
|
|
| 2.14, anonymous_ (?), 23:03, 20/10/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
 У меня войды. Есть и на musl, есть и на glibc. Токо дефолтно везде runit работает. С какого перепугу должен быть sysvinit?
| | |
| 2.18, Аноним (18), 07:09, 21/10/2018 [^] [^^] [^^^] [ответить]
| +/– |
Мимо, там давно runit. Кстати, намного лучше всех этих ваших sysvinit.
| | |
|
| 1.17, Аноним (17), 05:38, 21/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Эта реализация уже работает без портирующих патчей на fbsd и Hurd ядрах?
| | |
| 1.23, ryoken (ok), 11:44, 21/10/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 >> Добавлена проверка параметра ядра "init.autocon=1" и открытие процессом init >> собственной консоли.
Поясните плз. Как собссно на эту консоль посмотреть, после применения параметра ядра? :).
| | |
|
