… если он не просто «домашний для себя», а для какого-то потенциально полезного массам Open Source-проекта, связанного с CI/микросервисами/оркестровкой. (Вообще, у меня есть подозрение, что в Packet готовы помочь и другим Open Source-проектам, даже не связанным напрямую с тематикой CNCF [как пример — ядро Linux]. Просто тогда логичнее к ним напрямую обратиться.)
Но OpenStack продолжает жить и без Mirantis или вы хотите присоединиться к набирающему популярность мнению, что дни его сочтены? Могут ли быть сочтены, если так и не видно ему замены для тех самых крупных игроков?
Будь это всё прямо-таки правдой, не было бы огромных production-инсталляций на OpenStack у многих крупных ИТ-игроков, которые они поддерживают и развивают вот уже много лет (да и не только крупных — см. последний отчёт; при желании можно найти и какое-то «независимое» исследование по теме). В нынешних реалиях прослеживается ещё и интересный (и, что главное, рабочий!) тренд на комбинацию OpenStack с Kubernetes (недавно писал про eBay и SAP).
Продукты уровня OpenStack, конечно, могут быть далеки от идеала, но подобные посты ненависти, как уже многократно подтвердили в комментариях выше, будут всегда больше связаны с их неправильным применением (просто не для тих задач/масштабов или с недостаточным пониманием, как делать правильно в данном конкретном случае). Они (эти посты), конечно, могут пригодиться и другим потенциальным пользователям, но только при условии, что будут отброшены эмоции (не должны превалировать над технической частью, создавая ложное впечатление о сути) и по-настоящему хорошо описаны все детали, зачем, как и что из всего этого использовалось (сделаны соответствующие выводы, а в идеале — подтверждены другими специалистами, которые могут знать больше или банально увидеть что-то со стороны).
По первому впечатлению всё это никак не связано с cloud native (хотя, конечно, зависит от конкретной реализации…). Вот дословно ключевое требование в этом смысле: «Testing should involve cloud native computing, meaning containerization, microservices, orchestration or some combination».
Вопрос скорее в подходе, чем в конкретном решении. У нас есть свой стандарт дистрибутива, который мы повсеместно (тысячи железных/виртуальных серверов) используем, т.к. поддержка дополнительного специализированной платформы в долгосрочной перспективе получается «себе дороже» в нашем случае. Поэтому у нас утилита, которая подойдет для нужного нам (и, к слову, любого другого) дистрибутива, а не отдельный Linux-дистрибутив (который, впрочем, наверняка прекрасно решает и эту, и многие другие задачи — просто не наш вариант).
Пользовался Firefox со времён версий 0.x, в какой-то момент уходил на Chrome, потому что он стал заметно быстрее, но пару лет назад вернулся обратно, потому что: а) технически и удобством Firefox не проигрывает, б) не должно быть на рынке одного браузера одной компании (пусть это даже во многом симпатичный [и дружелюбный к миру Open Source] Google), в) очень нравится open web и вообще идейность (настоящая Open Source-ность) Mozilla. Самая значимая проблема в Firefox для меня сегодня заключается в том, что его уже перестают поддерживать некоторые сервисы (видеозвонки Slack, Google Hangouts, бета-версия новых Google AdWords), и именно это является самым нежелательным последствием монополии Google, которой надо избежать (слишком хорошо помню времена вёрстки под IE6…).
Посему — искренне желаю Mozilla вернуть хотя бы часть рынка и снова стать более заметным игроком на рынке браузеров. Никто другой не сделает это лучше их.
Средний относительный показатель «электронного мусора» на душу населения (per capita) составляет около 10 килограммов на человека. Самые высокие результаты у Гонконга (21,7 кг), Сингапура (19,95 кг) и Тайваня (19,13 кг)
Новая особенность AutoYaST — это ее новая интеграция с SaltStack и другими системами управления конфигурациями
Кто-нибудь в курсе, что скрывается за этим пространным «и другими системами» (так написано и на оригинальном сайте у openSUSE)? Интеграции готовой с другими ещё нет, но возможность заложена?
Очень поддерживаю! Ведь даже по этой легенде «системного администратора благодарные пользователи одаривают цветами и корзинками фруктов», а wikipedia рассказывает, что «The official SysAdmin Day website includes many suggestions for the proper observation of the holiday. Most common is cake and ice cream.» (сам этот сайт, к слову, тут).
P.S. А вообще, весь этот пост — копия прошлогоднего. Даже опечатку «[С ] 2006 года начал отмечаться…», например, сохранили…
Лично я без шуток люблю Perl, но всё-таки он действительно отживает своё. Ruby нам нравится (+ имеется хороший опыт с ним у всего отдела разработки), для задачи подходит, а также, как верно угадали в соседнем комментарии, сыграл свою роль Chef, используемый нами для IaC. Хотя сегодня, думаю, писали бы такое уже на Go.
Поддерживается разрешение DNS имен сервисов с помощью встроенной службы SkyDNS.
В экосистеме Kubernetes на смену ей уже приходит CoreDNS (недавно писал о нем), от тех же авторов.
В отличии от базовой платформы оркестрации контейнерами Kubernetes, Openshift привносит необходимые элементы для удобной и эффективной работы.
Не спора ради, а просто на заметку: Kubernetes по определению даёт только самую базу — в этом идея проекта. А минус OpenShift в том, что это такой Open Source, который в реальности полностью зависит от одного вендора и его интересов (в особенности, пока проект достаточно молод и не подхватили другие крупные игроки). Насколько это плохо — зависит от разных факторов, так что выбор каждого.
P.S. В рамках «введения в OpenShift» я бы ещё упомянул недавно представленный OpenShift.io. Пусть и не цель статьи, но для «кругозора» по проекту пригодится.
Многое из списка мы сами упоминали в статье про CNI. Но этот материал — перевод: тестировали не мы сами, а Machine Zone, причём уже больше года назад. Как известно, в мире Kubernetes всё очень динамично… Нам на сейчас этих данных хватило. Благо, авторы достаточно подробно описали своё окружение для тестирования, так что при желании можно воспроизвести с другими решениями: нужно только это самое желание (и время, конечно).
Продукты уровня OpenStack, конечно, могут быть далеки от идеала, но подобные посты ненависти, как уже многократно подтвердили в комментариях выше, будут всегда больше связаны с их неправильным применением (просто не для тих задач/масштабов или с недостаточным пониманием, как делать правильно в данном конкретном случае). Они (эти посты), конечно, могут пригодиться и другим потенциальным пользователям, но только при условии, что будут отброшены эмоции (не должны превалировать над технической частью, создавая ложное впечатление о сути) и по-настоящему хорошо описаны все детали, зачем, как и что из всего этого использовалось (сделаны соответствующие выводы, а в идеале — подтверждены другими специалистами, которые могут знать больше или банально увидеть что-то со стороны).
Посему — искренне желаю Mozilla вернуть хотя бы часть рынка и снова стать более заметным игроком на рынке браузеров. Никто другой не сделает это лучше их.
Кто-нибудь в курсе, что скрывается за этим пространным «и другими системами» (так написано и на оригинальном сайте у openSUSE)? Интеграции готовой с другими ещё нет, но возможность заложена?
P.S. А вообще, весь этот пост — копия прошлогоднего. Даже опечатку «[С ] 2006 года начал отмечаться…», например, сохранили…
В экосистеме Kubernetes на смену ей уже приходит CoreDNS (недавно писал о нем), от тех же авторов.
Не спора ради, а просто на заметку: Kubernetes по определению даёт только самую базу — в этом идея проекта. А минус OpenShift в том, что это такой Open Source, который в реальности полностью зависит от одного вендора и его интересов (в особенности, пока проект достаточно молод и не подхватили другие крупные игроки). Насколько это плохо — зависит от разных факторов, так что выбор каждого.
P.S. В рамках «введения в OpenShift» я бы ещё упомянул недавно представленный OpenShift.io. Пусть и не цель статьи, но для «кругозора» по проекту пригодится.