Впрочем

Почему через REST

msgpack is fine too

я не говорил, что сложно) но когда 1 контейнер = 1 сервис, то это очень наглядно видно всё

ТАК У МЕНЯ ТАК И ЕСТЬ. Только за сервис у меня взята - рабочая еденица.

Ты бы еще юникс утилиты запаковал в докер и приебашил к ним сокет

Ты бы еще юникс утилиты запаковал в докер и приебашил к ним сокет

у меня htop в докере)

Пиздец. Все.

просто если сломается сервер - так проще будет поднять с 0

на сервере только 1 программа - докер

всё остальное в контейнерах

чем больше програм стоит на сервере - тем выше риск того, что обновление системы что-то сломает

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

если физического доступа к серверу нет и KVM нет, а только доступ по ssh - это всё ненужные риски

чем больше програм стоит на сервере - тем выше риск того, что обновление системы что-то сломает

точно так же может быть kvm, lxc, lxd, rkt, etc...

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

Ну вот да

И базовую систему на хосте становится можно апдейтить атомарно

Транзакционно

Не завелось - откатил базовую прямо целиком

Не завелось - откатил базовую прямо целиком

воот

и получилась базовая coreos :D

с докером уже не страшно админить серверы

точно так же может быть kvm, lxc, lxd, rkt, etc...

И сколько человек в мире может так сделать на базе LXC или KVM?

и не страшно ставить апдейты ОС

(И сколько они попросят денег за труд?)

И потом эти компоненты общаются через HTTP REST

Ну вот я о том и говорю, что докер пропагандирует Unix way, микросервисы, одна задача = один контейнер и при этом сам представляет из себя монолитного монстра.

У меня на хосте голая система с lxc.

Problems?

Я еще в поезде еду, так что тут инет пропадает эпизодически.

И сколько человек в мире может так сделать на базе LXC или KVM?

Как так? Поставить lxc на хостовую систему, создать контейнер и накатить все внутри пакетами через тот же ansible? А что тут сложного, в чем rocket since?

Ну вот я о том и говорю, что докер пропагандирует Unix way, микросервисы, одна задача = один контейнер и при этом сам представляет из себя монолитного монстра.

Сам из себя он представляет программу на Golang И ничего не пропагандирует Но attack surface у него большой, это да

Как так? Поставить lxc на хостовую систему, создать контейнер и накатить все внутри пакетами через тот же ansible? А что тут сложного, в чем rocket since?

Атомарно заапдейтить ее теперь

У меня вот стояла Fedora 19 С KVM и более ни с чем

Но атомарно заапдейтить ее до 21 не удалось

Пришлось вообще сносить нахрен

Но то такое

Атомарно заапдейтить ее теперь

Смотря что подразумевается под атомарностью мы пакетами обновляемся. Внутри virtualenv со всеми зависимостями.

Смотря что подразумевается под атомарностью мы пакетами обновляемся. Внутри virtualenv со всеми зависимостями.

сама virtualenv зависит от питона

а питон поменяется после обновления системы

Смотря что подразумевается под атомарностью мы пакетами обновляемся. Внутри virtualenv со всеми зависимостями.

Что подразумевается под атомарностью, можно поглядеть в Project Atomic или в Ubuntu Snappy

Мажорно - нет

ну вот пример из недавней практики - жил был сервачок с 15.10 убунтой) питон стоял через https://github.com/yyuu/pyenv , была пара проектов там, каждый в своей pyenv-virtualenv, запускалось это всё через uwsgi... обновилась система на 16.04 LTS, uwsgi сломался и не захотел заводиться,

Если только на сервере не rolling release дистрибутив

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

ну вот пример из недавней практики - жил был сервачок с 15.10 убунтой) питон стоял через https://github.com/yyuu/pyenv , была пара проектов там, каждый в своей pyenv-virtualenv, запускалось это всё через uwsgi... обновилась система на 16.04 LTS, uwsgi сломался и не захотел заводиться,

Эм... 15.10 - вообще отдельная история. Там 2 Python. 3.4 и 3.5. Половина системы зависит от первого, половина от второго.

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

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

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

оно редко бывает, но бывает

а с докером тут риски в разы ниже

тестировать можно и нужно - но это лишние затраты времени (и денег, значит)

а малый бизнес даже за тесты не любит платить (то есть тестируют зачастую лишь основные процессы, типа "а может ли пользователь купить товар?", "а может ли пользователь отправить нам форму с текстом о том, что он нашел на сайте баг или сделать заказ?")

а с докером тут риски в разы ниже

Я вот не уверен, что в докере точно так же не сломался бы uwsgi.

Он был системный или в virtualenv?

И да, под обновлением между lts я имел в виду полное пересоздание контейнера, а не do-release-update

Он был системный или в virtualenv?

это был системный пакет

я его правда обновил через pip до этого

так что не совсем системный)

так через pip или системный? :)

он был установлен через apt, но потом обновлен через pip install -U

как-то так там было

бггг

Я вот не уверен, что в докере точно так же не сломался бы uwsgi.

а в докере можно было бы откатиться быстро

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

ну, мне ломать что-то не страшно) требований к аптайму больших у меня нет

страшно, когда оно быстро не чинится

если оно там на 5-10 минут сломалось - никто не заметит даже

если больше 15 - это уже плохо

ERROR: S client not available

в случае с докером (без тестирования) - это решилось бы за 1-2 минуты (обновили на новый контейнер, попробовали запустить, ууупс, запустили повторно старый контейнер)

пустой lxc, ансибл, переключение фронта со старого на новый, упс, переключение фронта с нового на старый

но у хомячка пиар конечно лучше :) то есть у китёнка

с lxc я не работал напрямую, но так должно быть дольше

я докер сравниваю с App Store

то есть можно поставить какой-то софт и не думать про его зависимости

lxc по идее теми же преимуществами обладает, но меньше распиарен

дольше что чем что? docker build работает быстрее, чем ansible/salt работают внутри lxc? :D

я вот всё жду когда софт будет помимо deb/rpm распространяться как Dockerfile с инструкциями)

от JetBrains жду такого как минимум

для их YouTrack'а и прочего софта

дольше что чем что? docker build работает быстрее, чем ansible/salt работают внутри lxc? :D

я не тестировал, а что, медленнее?

там разные слои же есть

что-то закешировано (сама базовая система, какие-то базовые пакеты)

должно быть быстрее

начиналось все с того, что базовую систему обновили :)

а ну так базовая система это просто официальный образ

на него сверху пакеты с зависимостями и питон

а в питон дальше requirements.txt

в общем-то я делаю всё на базе официального питон-альпин образа

а в lxc базовая система как генту из сорцов? :)

вот пример докерфайла

https://dpaste.de/URTa

lxc-create -n lorddaedra -t alpine ...

а с lxc там как происходит распространение образа?

то есть создают образ, как-то запускают его , ставят туда через энсибл софт, а дальше?

в докерхабе есть автобилды

https://docs.docker.com/docker-hub/builds/

я так и знал, что по пункту "быстрее" возражений не будет, поэтому начнут докерхаб вынимать :)

я просто не люблю спорить, когда до конца не уверен

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

в этом аспекте "гамна натаскат с хаба" или "своего туда насовать", конечно лучше