|
|
3.11, Аноним (-), 11:57, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
А чего все тут на Go кидаются в каждой новости?
Какие у него _объективные_ минусы?
| |
|
4.13, Michael Shigorin (ok), 13:12, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> А чего все тут на Go кидаются в каждой новости?
> Какие у него _объективные_ минусы?
Очевиднейший:
---
The linkers in the gc tool chain (5l, 6l, and 8l) do static linking. All Go binaries therefore include the Go run-time, along with the run-time type information necessary to support dynamic type checks, reflection, and even panic-time stack traces.
A simple C "hello, world" program compiled and linked statically using gcc on Linux is around 750 kB, including an implementation of printf. An equivalent Go program using fmt.Printf is around 1.9 MB, but that includes more powerful run-time support and type information.
--- http://golang.org/doc/faq#Why_is_my_trivial_program_such_a_large_binary
Причём в этом ответе они передёргивают аж два раза: во-первых, мало кому нужен именно статический сишный hello; во-вторых, этот "more powerful runtime" вряд ли кто-то станет выковыривать из бинарника, которому такая внагрузка ровным счётом никаких плюсов не даёт.
Что само по себе настораживает.
| |
|
5.14, Аноним (-), 14:00, 22/05/2015 [^] [^^] [^^^] [ответить] | +/– | Ну насколько я знаю при создании языка предполагалось использовать его для систе... большой текст свёрнут, показать | |
|
|
7.17, Sokoloff (?), 16:56, 22/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Есть разница между "можно статически" и "только статически".
Ну есть еще gccgo, он собирает не статически. Да и правильнее сравнивать GO не с сями а с питоном и руби. Его странно позиционируют, как системный, но если посмотреть примеры, то большинство использует его именно для веб-сервисов. А мало кто пишет веб-сервисы на сях, обычно шарашат на скриптовых языках. И если сложить интерпретатор, его библиотеки да еще apache/nginx, то тут 5яти мегабайтный гошный бинарник, уже и выигрывает.
| |
|
8.25, Аноним (-), 22:50, 23/05/2015 [^] [^^] [^^^] [ответить] | +/– | Но гуглем по дефолту сватается другое и с странными подходами Они тем более не ... текст свёрнут, показать | |
|
7.18, Аноним (-), 17:20, 22/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
Миша ты того ... устарел слегка :) В Go - не "только статически", но надо ручками юзать другой линкер и прочий гимор. Да сделают, куда денутся :)
| |
|
|
5.16, csdoc (ok), 14:09, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> А чего все тут на Go кидаются в каждой новости?
>> Какие у него _объективные_ минусы?
> Очевиднейший:
> The linkers in the gc tool chain (5l, 6l, and 8l) do static linking.
> All Go binaries therefore include the Go run-time
это практическая реализация принципов UNIX-way и KISS.
что не удивительно, потому что Go делали те же самые люди,
которые перед тем делали UNIX.
называть это минусом - как-то странно.
> во-вторых, этот "more powerful runtime" вряд
> ли кто-то станет выковыривать из бинарника, которому такая внагрузка ровным счётом
> никаких плюсов не даёт.
плюсы есть - деплоймент новой версии приложения оказывается тривиальным процесом,
нет никаких проблем с зависимостями. Причем, памяти в процессе работы такая программа
будет занимать меньше, чем аналогичная программа на Java, потому что тут нет JIT
и бинарный код формируется прямо в процессе компиляции, а не во время исполнения.
| |
|
6.21, Алексей Морозов (ok), 08:42, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> плюсы есть - деплоймент новой версии приложения оказывается тривиальным процесом,
Как-то у меня был проект, на плюсах, который нам в итоге пришлось собирать статически. И вот я так доложу - деплоймент на площадку 6 статически собранных бинарей, в сумме тянувших на гиг с лишним, был нифига не тривиальным занятием. Точнее, конечно, тривиальным, когда не надо быстро, а когда надо быстро - там-то и начинался весь секес.
| |
|
5.19, Аноним (-), 17:46, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
>> А чего все тут на Go кидаются в каждой новости?
>> Какие у него _объективные_ минусы?
> Очевиднейший:
Новое оно. Все шишки ещё только предстоит набить :-(
Остальное - всё фигня, и решаемая и уже над многим из - работают.
| |
|
4.27, Аноним (-), 22:53, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Какие у него _объективные_ минусы?
Используется всякой хипстотой, считающей что за них подумает компилер и рантайм. В системных тулзах это ессно ведет к туевой хуче дыр всех мастей (и Docker в этом плане очень показателен). А еще зачем-то все в статику линкует.
...а в OVZ очевидный минус - требуют левое кастомное ядро. Это очень жирный минус.
| |
|
5.32, AlexAT (ok), 23:23, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> ...а в OVZ очевидный минус - требуют левое кастомное ядро. Это очень
> жирный минус.
Есть ещё один минус. Ядро тоже не безбажно, а кастомное ядро с такого размера патчсетом - вдвое более не безбажно. Соответственно если в PV падает ядро - у вас падает только VM, если в OpenVZ падает ядро - падает вся нода. PV-механизмы тоже не безбажны, но гипервизоры всё-таки помельче по размеру будут, чем ядро. Ну и юзерспейс с PV-часть гипервизора всё-таки не взаимодействует, а вот контейнеры с ядром... Т.е. шансов уронить контейнерную ноду куда больше.
| |
|
6.33, Michael Shigorin (ok), 23:26, 23/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Есть ещё один минус. Ядро тоже не безбажно, а кастомное ядро с
> такого размера патчсетом - вдвое более не безбажно.
Ошибаетесь -- люди из ovz team нашли и починили немало багов, включая весьма неприятные и ни разу не относящиеся к их парафии.
> Соответственно если в PV падает ядро - у вас падает только VM, если в
> OpenVZ падает ядро - падает вся нода. PV-механизмы тоже не безбажны,
> но гипервизоры всё-таки помельче по размеру будут, чем ядро.
Занятные сравнения. А если падает ядро на железке? :) А мельче ли гипервизоры, чем ovz?..
| |
|
7.34, AlexAT (ok), 23:35, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Занятные сравнения. А если падает ядро на железке? :) А
> мельче ли гипервизоры, чем ovz?..
В данном случае гипервизор надо сравнивать именно с ядром в целом, так как в работе OpenVZ участвует львиная доля кода самого ядра. И если бахнется ядро - всем будет пофиг, бахнулся там код OpenVZ, или что-то ещё. Ну и любая мало-мальски серьёзная дыра в ядре (в любом коде, хоть OpenVZ, хоть нет) превращается в дыру всей ноды. C гипервизором же, повторюсь, юзерспейс виртуалок взаимодействует либо никак, либо крайне ограниченно. В итоге сначала придётся получать рута на VM, потом искать настолько же серьёзную дыру в гипервизоре.
| |
|
|
9.37, й (?), 17:45, 26/05/2015 [^] [^^] [^^^] [ответить] | +/– | а nf_conntrack ip_conntrack_disable_ve0 1 не зацепило да, я в курсе, что оно си... текст свёрнут, показать | |
|
|
|
|
|
|
|
2.3, delin (?), 22:18, 21/05/2015 [^] [^^] [^^^] [ответить]
| +6 +/– |
> Поздно. Docker наше все!
Правильно, тёплое круче мягкого!
| |
2.42, й (?), 19:09, 27/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Поздно. Docker наше все!
расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
docker-way: завершить старый, подождать (даунтайм), поднять новый.
ну, либо извращаться с редиректами на iptables на хост-системе.
| |
|
|
|
|
6.47, й (?), 19:26, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
>>> *Почти* http://www.luffy.cx/en/blog/2015-hotfix-qemu-venom.html docker-way.
>> а причём тут docker? там про qemu рассказывают.
> Апгрейд с downtime=0 === Не искать лёгких путей.
> Ну, мож, и не докер. Но кроваво-энтерпрайзно точно. [И да, кластер-шардер из
> докеров -- тоже!]
маленький нюанс: xen/kvm можно live-мигрировать с хоста на хост. а докер нельзя.
| |
|
|
|
3.46, Andrey Mitrofanov (?), 19:24, 27/05/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> Поздно. Docker наше все!
> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
++Отдельное спасибо за вкусный corner-case этой свистоперделки.
| |
|
4.53, й (?), 20:05, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
на здоровье. у меня есть нехилый опыт докера в продакшне и я действительно считаю, что докер пока многого не умеет и должен быть лучше.
на данный момент я его переел: недостатки перевешивают плюсы.
а основной плюс докера: соединение configuration management с запуском виртуалок. очень хорошая идея, но докер пока сыроват. впрочем, если openvz таки нормально скрестят с ансиблем, нафиг тот докер.
| |
|
|
4.50, й (?), 19:41, 27/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
> через Blue/Green Deployment.
> тут теория: http://martinfowler.com/bliki/BlueGreenDeployment.html
> тут практика: http://arojgeorge.ghost.io/a-continuous-delivery-example/
я в курсе, что это такое. итак, практическая задача: обновить docker-контейнер, слушающий на 80 порту, без даунтайма (переключить со старого на новый).
у docker вариант один: делать балансировщик на iptables. по линкам даже это не рассказано.
вы знаете другие варианты?
| |
|
5.52, csdoc (ok), 20:00, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> практическая задача: обновить docker-контейнер, слушающий
> на 80 порту, без даунтайма (переключить со старого на новый).
> у docker вариант один: делать балансировщик на iptables. по линкам даже это
> не рассказано.
> вы знаете другие варианты?
да, в качестве балансировщика использовать nginx или haproxy.
| |
|
6.54, й (?), 20:08, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> в качестве балансировщика использовать nginx или haproxy.
ну-ну. лучше бы возможность переключить порт, на который забинден контейнер.
нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081, а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё равно кривовато.
| |
|
7.55, й (?), 20:13, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> ну-ну. лучше бы возможность переключить порт, на который забинден контейнер.
> нет, можно сделать так: старый контейнер слушает на 8080, новый на 8081,
> а nginx'у мы говорим, куда коннектиться, через jenkins, например. но всё
> равно кривовато.
особенно кривовато это становится, когда у нас новый контейнер становится старым. ну нахрена эти пляски на пустом месте?
| |
|
8.57, csdoc (ok), 20:26, 27/05/2015 [^] [^^] [^^^] [ответить] | +/– | поздравляю, вы только что изобрели метод Blue Green Deployment других вариантов... текст свёрнут, показать | |
|
9.59, й (?), 20:33, 27/05/2015 [^] [^^] [^^^] [ответить] | +/– | есть мы апдейтим код прямо в контейнере и говорим graceful reload демону но эт... текст свёрнут, показать | |
|
10.63, csdoc (ok), 21:18, 27/05/2015 [^] [^^] [^^^] [ответить] | +/– | далеко не весь софт запускается в виде демонов и далеко не весь софт умеет де... текст свёрнут, показать | |
|
11.64, й (?), 21:29, 27/05/2015 [^] [^^] [^^^] [ответить] | +/– | ну не на cgi-скриптах на перле же и не из inetd в java-мире скорее, конкретны... текст свёрнут, показать | |
|
12.65, csdoc (ok), 22:16, 27/05/2015 [^] [^^] [^^^] [ответить] | +/– | это так есть в общем случае этим методом задача не решаема а что это за стеки ... текст свёрнут, показать | |
|
13.66, й (?), 22:48, 27/05/2015 [^] [^^] [^^^] [ответить] | +/– | unicorn, uwsgi даже в банально php хоть mod_php, хоть php-fpm проблем с этим ... текст свёрнут, показать | |
|
14.67, csdoc (ok), 23:42, 27/05/2015 [^] [^^] [^^^] [ответить] | –1 +/– | Программировать на языке Java - это нормально https www youtube com watch v k... текст свёрнут, показать | |
|
|
16.71, csdoc (ok), 00:18, 10/06/2015 [^] [^^] [^^^] [ответить] | +1 +/– | Скорее уж как констатация факта http habrahabr ru post 201612 Java навсегда ... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
|
|
|
|
3.56, AlexAT (ok), 20:19, 27/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> docker-way: завершить старый, подождать (даунтайм), поднять новый.
И давно haproxy отменили?
| |
|
4.60, й (?), 20:34, 27/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
>> docker-way: завершить старый, подождать (даунтайм), поднять новый.
> Возможно, http://www.opennet.me/opennews/art.shtml?num=42315
и давно criu поддерживает live migration? это чисто save-restore. я выше об этом писал.
| |
4.62, Andrey Mitrofanov (?), 20:48, 27/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> расскажете мне, как обновить контейнер, слушающий на 80 порту, без даунтайма?
>> docker-way: завершить старый, подождать (даунтайм), поднять новый.
> Возможно, http://www.opennet.me/opennews/art.shtml?num=42315
Там doom секунд на 5 на видео замирает. Да, tcp-соединение(vnc) не успевает таймаут словить. Но, где кончается то замирание и начинается даунтайм[!=0], я вас.
| |
|
|
|
1.4, AlexAT (ok), 22:30, 21/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
Они ещё где-то применяются? Паравиртуализация стала настолько дешёвой, а для изоляции - cgroups настолько выросли, что необходимость в openvz уже сильно сомнительна. Хотя, конечно, ploop - ценная вещь сама по себе, даже без OpenVZ.
| |
|
2.5, crypt (ok), 22:45, 21/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
видимо, поэтому опрос как бы спрашивает "ну! ну! что нам сделать, чтобы вы нас купили?!"
| |
|
|
4.10, Michael Shigorin (ok), 11:16, 22/05/2015 [^] [^^] [^^^] [ответить]
| +4 +/– |
> написать самим обертку вокруг cgroups влом ?
Посмотрите, на какой основе cgroups вообще возникли и кто их пилит, что ли...
| |
|
5.28, Аноним (-), 23:04, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Посмотрите, на какой основе cgroups вообще возникли и кто их пилит, что ли...
Им бы еще неплохо вовремя понять что вся эта трахoмyдия с кастомными ядрами - всех уже подутомила. Это нынче приводит к тому что OVZ многими воспринимается как геморная и obsoleted штука. Такая политика партии зарубает много применений. При том чаще всего у разработчиков и прочих заинтересованных, которым в результате все это становится вообще не надо.
Вон опенвртшники - нынче сватают докер-шмокер как один из варантов сборочной среды. На этом месте мог бы в принципе быть и OVZ. Но не будет. Потому что вкатывать какие-то кастомные ядра на машину разработчика - даром никому не надо. А OVZ сватают это как основной сценарий использования. Что безнадежно протухло по современным меркам.
| |
|
6.29, Michael Shigorin (ok), 23:09, 23/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Потому что вкатывать какие-то кастомные ядра на машину разработчика
> - даром никому не надо. А OVZ сватают это как основной сценарий использования.
> Что безнадежно протухло по современным меркам.
Для серверов-то протухло, здрасьте? А на десктоп и не сватали, хотя я таких людей знаю.
| |
|
7.31, AlexAT (ok), 23:19, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Для серверов-то протухло, здрасьте? А на десктоп и не сватали, хотя
> я таких людей знаю.
Ещё не протухло, но активно подтухает. С ядром от RH7 у OpenVZ'шников всё печально и уныло, релизу уже год почти, а OpenVZ так и нет. А новое ядро там с легкостью все накладные расходы на ту же паравиртуализацию окупит.
| |
7.68, Аноним (-), 22:24, 09/06/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Для серверов-то протухло, здрасьте?
Да привет уж. С практической точки зрения - лучше всего когда разработчики разрабатывают в том же окружении которое на десктопе. Потом наименьшее количество проблем. А если это принципиально иная среда - там грабли обпрыгивать задолбаешься. А хуже OpenVZ в сложности обкатки на локальных окружениях у разработчиков только MS Azure какой-нибудь. Я бы не стал их поздравлять с таким соседством и сравнением.
> А на десктоп и не сватали, хотя я таких людей знаю.
Ну отлично, а я буду считать такие подходы неудобными и полагать что их вынос в obsoleted - правильно и заслуженно.
| |
|
|
9.74, Аноним (-), 01:03, 10/06/2015 [^] [^^] [^^^] [ответить] | +/– | У микрософта как раз с этим большие проблемы Эти упыри даже для своего ажура-аб... большой текст свёрнут, показать | |
|
|
|
|
|
|
3.23, Аноним (-), 14:16, 23/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
плюсую
опрос заполнил, убедился что главные вопросы там именно на эту тему
тока результаты опроса или я не нашел или опубликуют потом
или не опубликуют
| |
|
2.6, delin (?), 23:24, 21/05/2015 [^] [^^] [^^^] [ответить]
| +3 +/– |
> Они ещё где-то применяются? Паравиртуализация стала настолько дешёвой, а для изоляции -
> cgroups настолько выросли, что необходимость в openvz уже сильно сомнительна. Хотя,
> конечно, ploop - ценная вещь сама по себе, даже без OpenVZ.
Применяется. Во первых ещё не на столько она дешёвая стала паравиртуализация, во вторых, гибкость в управлении у OpenVZ и прочих контейнеров лучше.
| |
2.9, ктотогдето (?), 10:44, 22/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Активно используем OpenVZ в инфраструктуре CI/CD. Практика эксплуатации показала, что на серверах с Xeon E5-2680 2.70GHz мы можем относительно комфортно запускать до 3-х LAMP-контейнеров (в которых далеко не "hello world" крутится) на ядро. В пиках бывает до 5 контейнеров на ядро, но это уже не так комфортно :) Что будет с сервером если запустить такое-же количество VM я даже представить себе боюсь.
| |
|
3.22, Алексей Морозов (ok), 08:49, 23/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Активно используем OpenVZ в инфраструктуре CI/CD. Практика эксплуатации показала, что
> на серверах с Xeon E5-2680 2.70GHz мы можем относительно комфортно запускать
> до 3-х LAMP-контейнеров (в которых далеко не "hello world" крутится) на
> ядро. В пиках бывает до 5 контейнеров на ядро, но это
> уже не так комфортно :) Что будет с сервером если запустить
> такое-же количество VM я даже представить себе боюсь.
Вообще, взрослые дядьки десятками виртуалки на одной хардварной ноде запускают, в || даже релизные тесты такие есть :). Но там ключевые моменты - развести на разные ноды тех, кто будет жрать IO и процессор, ну и чтобы памяти всем хватило.
Но вообще cgroups / lxc - в той же весовой категории, что неудивительно, учитывая происхождение этих самых lxc, разве что не настолько mature. Но, в принципе, некоторым уже хватает.
| |
|
2.20, Аноним (-), 18:15, 22/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Паравиртуализация стала настолько дешёвой
Запускаем KVM виртуалку с virtio. Активно грузим дисковый IO в виртуалке и смотрим, как процесс qemu отжирает 150% CPU хост системы. Ну уж нет.
| |
|
3.30, AlexAT (ok), 23:16, 23/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Запускаем KVM виртуалку с virtio. Активно грузим дисковый IO в виртуалке и
> смотрим, как процесс qemu отжирает 150% CPU хост системы. Ну уж
> нет.
Запускаем Xen виртуалку в PV. Активно грузим дисковый IO... и понимаем, что он упёрся либо в шину, либо в сеть (если iSCSI). Ну а если у вас требуемая пропускная способность дисковой системы для одной VM такая, что способна хотя бы два гиговых линка под iSCSI нагрузить полностью - нахрена вам в таком случае виртуализация? Всё равно больше одной такой машины на типовом железе запускать смысла нет. Кстати, в случае Xen PV qemu банально выкидывается из цепочки.
| |
|
4.38, й (?), 11:55, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Запускаем Xen виртуалку в PV. Активно грузим дисковый IO...
и получаем просадку в 20-30% по сравнению с bare metal.
| |
|
5.39, pavel_simple (ok), 17:32, 27/05/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> Запускаем Xen виртуалку в PV. Активно грузим дисковый IO...
> и получаем просадку в 20-30% по сравнению с bare metal.
что с зеном сделали за послетние пять лет что из 2% стало 20?
| |
|
6.40, й (?), 18:52, 27/05/2015 [^] [^^] [^^^] [ответить]
| +/– |
пять лет назад тоже 20 было, сам помню.
говорят, квм чуть получше в плане io, но всё равно процентов 15.
у контейниризации оверхед гораздо меньше.
| |
|
7.41, й (?), 18:55, 27/05/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
> пять лет назад тоже 20 было, сам помню.
el5 + диски виртуалок из lvm
| |
7.79, Аноним (-), 14:06, 27/07/2016 [^] [^^] [^^^] [ответить]
| +/– |
> пять лет назад тоже 20 было, сам помню.
не было такого никогда
давай прувы или gtfo
| |
|
|
|
4.78, Аноним (-), 16:50, 10/06/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Ну а если у вас требуемая пропускная способность дисковой системы для одной VM такая, что способна хотя бы два гиговых линка под iSCSI нагрузить полностью - нахрена вам в таком случае виртуализация?
В виртуалке всего лишь запущен emerge-webrsync
| |
|
|
|
1.36, tehnikpc (ok), 18:39, 24/05/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> Проект OpenVZ проводит опрос среди своих пользователей
своих системных администраторов
| |
|