Прямо с первых строк статьи начинается подтасовка фактов. Надеятся что на хабре читатели не знают английский по меньшей мере странно.
Except for the case of storing a lot of binary files, when Subversion repositories could be significantly smaller than Git ones (because Subversion’s xdelta delta compression algorithm works both for binary and text files)
После чего автор берет свн репозитарий исходных кодов без бинарей (фактов о наличии в нем бинарей в статье не приведено, да и количество файлов при размере 213 МБ намекает) и радостно рапортует, что текст git хранит лучше.
Пусть автор попробует создать репозиторий с 100мб бинарями. И сконвертит его в гит. Убедится что гит умрет, и включит LFS. После чего с удивлением узнает, что LFS ничего ни о каких дифах не знает и тупо хранит каждую измененную версию в отдельном файле. Итого по 100 и более мб на каждую ревизию. Поэтому git безусловно крут, но вот для смешанного хранилища бинарей и исходных кодов ничего лучше svn так и не придумали (maven, artifactory… это не vcs у них своя ниша)
странно в докладе про деплой ни одного слова про capistrano
более того если большая часть доклада про деплой с помощью ansible то было-бы логично упомянуть ansistrano
У меня сложилось впечатление, что просто пока мало документации. Я писал про папку /scripts. В документации тоже есть упоминания про запуск скриптов при старте контейнера. Просто пока не понятно как. А пока вот такой костыль.
Я не думаю что слияние убило проект. Просто для старой версии было накоплено множество готовых решений. Теперь нужно набирать новую базу рецептов. С бекапами я уверен тоже можно что-то придумать.
Ограниченная команда на зарплате эффективнее кучи энтузиастов в свободное время (если энтузиастов не тысячи). Кстати практически весь открытый софт по большей части пишется людьми на зарплате, которые получают зарплату именно за разработку открытого софта. Например в ядре прилично кода Red Hat, да и Parallels тоже свои патчи продвигает в ванильное ядро.
Говорить про проигранный рынок тоже сложно. Есть масса OpenVZ хостингов. А вот про хостинги на LXC лично я не слышал. Докер хостингов тоже видел всего пару проектов. Просто не сильно агрессивная по сравнению с тем-же докером реклама (про OpenVZ и так все знают). Вон xen тоже не особо рекламируется, а на нем Amazon EC2 работает.
Про LXC у меня сложилось мнение что это недо-OpenVZ.
Раньше LXC не было. Были патчи комманды OpenVZ на ванильное ядро. Постепенно эти патчи добавлялись прямо в ванильное ядро. Соответственно уменьшался объем OpenVZ патчей которые надо было применить дополнительно. На базе функционала добавленного в ванильное ядро был разработан LXC. Но в нем по прежнему не весь функционал OpenVZ.
Вот тред где люди перешли с OpenVZ на LXC и им это не понравилось https://forum.proxmox.com/threads/moving-to-lxc-is-a-mistake.25603/
А в целом если OpenVZ набор костылей, то LXC тоже набор костылей но не полный.
Docker это надстройка над LXC. Поэтому говорим Docker подразумеваем LXC. Т.е. сравнивать OpenVZ и Docker не совсем корректно.
Далее, лично мне Docker не понравится. Все то-же самое можно сделать на чистом LXC/OpenVZ, но без недостатков самого Docker. При этом в Docker есть все недостатки присущие LXC + его собственные. У меня основная претензия — это отсутствие возможности сохранять данные в самом контейнере. Я понимаю что это сделано специально но мне такая архитектура не нравится.
Вообще у меня сложилось впечатление что докер ждет судьба VirtualBOX. Все слышали, многие используют дома/на рабочем ПК, но на серверах стоит VmWare. Так и тут. Докер удобен разработчикам, но ставить в продакшен неизвестно чьи образы с возможно присутствующими бекдорами… А если ВСЕ собирать самим то докер теряет половину достоинств. Да и для деплоя есть и другие инструменты. Они сложнее чем докер и разработчики не хотят в них разбираться. Но на продакшене есть админы, а админам Puppet/Ansible/Chef/etc… привычнее и универсальнее. Но я повторюсь мне Docker не понравится поэтому я предвзят.
После чего автор берет свн репозитарий исходных кодов без бинарей (фактов о наличии в нем бинарей в статье не приведено, да и количество файлов при размере 213 МБ намекает) и радостно рапортует, что текст git хранит лучше.
Пусть автор попробует создать репозиторий с 100мб бинарями. И сконвертит его в гит. Убедится что гит умрет, и включит LFS. После чего с удивлением узнает, что LFS ничего ни о каких дифах не знает и тупо хранит каждую измененную версию в отдельном файле. Итого по 100 и более мб на каждую ревизию. Поэтому git безусловно крут, но вот для смешанного хранилища бинарей и исходных кодов ничего лучше svn так и не придумали (maven, artifactory… это не vcs у них своя ниша)
более того если большая часть доклада про деплой с помощью ansible то было-бы логично упомянуть ansistrano
Я не думаю что слияние убило проект. Просто для старой версии было накоплено множество готовых решений. Теперь нужно набирать новую базу рецептов. С бекапами я уверен тоже можно что-то придумать.
Говорить про проигранный рынок тоже сложно. Есть масса OpenVZ хостингов. А вот про хостинги на LXC лично я не слышал. Докер хостингов тоже видел всего пару проектов. Просто не сильно агрессивная по сравнению с тем-же докером реклама (про OpenVZ и так все знают). Вон xen тоже не особо рекламируется, а на нем Amazon EC2 работает.
Раньше LXC не было. Были патчи комманды OpenVZ на ванильное ядро. Постепенно эти патчи добавлялись прямо в ванильное ядро. Соответственно уменьшался объем OpenVZ патчей которые надо было применить дополнительно. На базе функционала добавленного в ванильное ядро был разработан LXC. Но в нем по прежнему не весь функционал OpenVZ.
Вот тред где люди перешли с OpenVZ на LXC и им это не понравилось https://forum.proxmox.com/threads/moving-to-lxc-is-a-mistake.25603/
А в целом если OpenVZ набор костылей, то LXC тоже набор костылей но не полный.
Далее, лично мне Docker не понравится. Все то-же самое можно сделать на чистом LXC/OpenVZ, но без недостатков самого Docker. При этом в Docker есть все недостатки присущие LXC + его собственные. У меня основная претензия — это отсутствие возможности сохранять данные в самом контейнере. Я понимаю что это сделано специально но мне такая архитектура не нравится.
Вообще у меня сложилось впечатление что докер ждет судьба VirtualBOX. Все слышали, многие используют дома/на рабочем ПК, но на серверах стоит VmWare. Так и тут. Докер удобен разработчикам, но ставить в продакшен неизвестно чьи образы с возможно присутствующими бекдорами… А если ВСЕ собирать самим то докер теряет половину достоинств. Да и для деплоя есть и другие инструменты. Они сложнее чем докер и разработчики не хотят в них разбираться. Но на продакшене есть админы, а админам Puppet/Ansible/Chef/etc… привычнее и универсальнее. Но я повторюсь мне Docker не понравится поэтому я предвзят.