IT-консультант
К 2021 году Ansible уже стал стандартом в администрировании. В трёх из четырёх DevOps вакансий просят знание Ansible. Из них только в одной из четырёх — это преимущество, в остальных — требование.
Для тех, кто еще не работал c Ansible или только пользовался ролями и плейбуками, написанными коллегами, мы готовим новый курс «Ansible: от первых шагов до большого проекта».
Эта статья — развернутый ответ на вопрос, который нам периодически задают: чем werf отличается от Helm? На первый взгляд можно предположить, что задача у них примерно одинаковая: автоматизировать деплой приложений в Kubernetes. Но всё, конечно, немного сложнее…
Привет, Хабр!
На связи снова Максим Горшков, специалист по информационной безопасности Cloud4Y. Будучи следователем по расследованию киберпреступлений в недавнем прошлом, я изрядно насмотрелся на компании, которые пострадали из-за недостаточно серьёзного отношения к инфобезу.
Хочу поднять вопрос о деятельности, результаты которой обычно незаметны, но крайне важны для бизнеса. Я имею в виду кибербезопасность.
Хабр, привет! Меня зовут Николай Бутенко, я руководитель Private Cloud в Mail.ru Cloud Solutions, и сегодня хочу обсудить с вами одно из самых больших заблуждений, с которыми я встречаюсь каждый день. Если вы когда-либо работали с облачными сервисами, то наверняка знаете о распространенном мнении, что перенос приложения в облако является панацеей от всех возможных с ним проблем. Я регулярно сталкиваюсь с такой позицией на встречах с самыми разнообразными заказчиками.
К сожалению, это мнение ошибочно. Часть ответственности лежит и на самом клиенте. Необходимо придерживаться определенных принципов в построении Cloud Native-приложений, чтобы обеспечить их отказоустойчивость, причем как на уровне программного кода, так и на уровне нижележащей инфраструктуры. При этом следует понимать, что даже соблюдение этих принципов не гарантирует полной защиты от всех рисков.
Поэтому если перед вами стоит задача построить на 100% отказоустойчивую и высокодоступную (High Availability, HA) систему, я рекомендую придерживаться подхода Multicloud Native Service, сочетающего лучшее в подходах Multicloud и Cloud Native. Такой подход не сводится только к использованию контейнеров: чтобы приложение могло пережить любой отказ, нужно подумать и об инфраструктуре, в частности использовать не одну, а минимум две независимые площадки, например провайдера публичного облака и частную инфраструктуру.
Я подробно расскажу о преимуществах и вариантах реализации этого подхода, о сложностях, с которыми можно столкнуться при его использовании, и методах их решения, а также о том, какими характеристиками должен обладать идеальный облачный провайдер.
Коротко о том, чем руководствоваться при старте изучения языка и как не расстраиваться, когда не получается.
Как выбрать компетентного репетитора, который научит современному языку.
Возможно, вы уже в курсе, что сейчас в России цены на жёсткие диски большого объёма и SSD стремительно растут, а по компьютерным магазинам мечутся люди, в спешке покупающие комплектующие для новых компьютеров. Причиной этого ажиотажа стала новая криптовалюта Chia, для добычи которой нужны большие HDD и износостойкие SSD.
Chia предлагает модель экологичного майнинга, не требующего колоссальных затрат электроэнергии и уменьшающую парниковые выбросы, так как огромное количество электростанций до сих пор работает на ископаемом топливе.
Для лучшего понимания всего что связано с этой криптовалютой, вашему вниманию предлагается расшифровка моего разговора с майнером Chia, который состоялся вечером 21 апреля 2021 года. Я выступаю в роли продавца SSD, а майнер в роли повторного покупателя, который в ходе разговора делает coming-out. В ходе этого разговора я узнал много нового о Chia.
Добрая четверть моего рабочего времени за последний год ушла на обновление архитектуры Учи.ру. С ростом продуктов и количества пользователей увеличился и клубок зависимостей в монолите. Выделяя из него части и набивая на этом пути шишки, я не раз задумывался о том, как мы к этому пришли. Волей-неволей вспоминаешь, с чего все начиналось.
В этом посте я попробовал собрать историю архитектуры Учи.ру. В нем нет фрагментов кода и исчерпывающих технических подробностей. О нашем опыте выделения микросервисов для решения некоторых задач образовательной платформы — в следующих публикациях.
Когда я смотрю фантастические фильмы или ролики о том, какие гаджеты и техника нас будет окружать через 10-20-30 лет, то чаще всего вижу разные прозрачные экраны, голограммы или проекции на руку, лоб или пупок. Чтобы всем этим управлять нужен всего-то один палец. Всё выглядит красиво и фантастично. Но что, если я скажу вам, что подобные концепции, возможно, ложные?
Не считая того, что там нет будущего, потому что авторы просто гиперболизируют уже существующие сенсорные экраны до предела, там нет взаимодействия. Что, если я скажу, что настоящее будущее взаимодействия в ваших руках.
Это продолжение практикума по развертыванию Kubernetes-кластера на базе облака Mail.ru Cloud Solutions и созданию MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube.
Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу все этапы разработки Cloud-Native приложений на K8s: от запуска кластера до построения CI/CD и разработки собственного Helm-чарта.
Напомню, что в первой части статьи мы выбрали архитектуру приложения, написали API-сервер, запустили Kubernetes c балансировщиком и облачными базами, развернули кластер RabbitMQ через Helm в Kubernetes. Сейчас во второй части мы настроим и запустим приложение для преобразования аудио в текст, сохраним результат и настроим автомасштабирование нод в кластере.
О Kubernetes и его роли в построении микросервисных приложений известно, пожалуй, большинству современных IT-компаний. Однако при его внедрении часто возникает вопрос — какой вариант установки выбрать: Self-Hosted или Managed-решение от одного из облачных провайдеров. О недостатках первого варианта, думаю, известно всем, кто проходил через ручное конфигурирование K8s: сложно и трудоемко. Но в чем лучше Cloud-Native подход?
Я Василий Озеров, основатель агентства Fevlake и действующий DevOps-инженер (опыт в DevOps — 8 лет), покажу развертывание Kubernetes-кластера на базе облака Mail.ru Cloud Solutions. В этом цикле статей мы создадим MVP для реального приложения, выполняющего транскрибацию видеофайлов из YouTube.
Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.
Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.
Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе — D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.
Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.
Виртуальные рабочие столы на базе VDI — удачное решение, если нужно развернуть сразу много пользовательских десктопов с едиными настройками. Сотрудник подключается с любого устройства и получает привычный и удобный интерфейс с доступом ко всей офисной инфраструктуре — так выглядит идеальная картина. Но добиться ее в реальности можно, только если учесть все факторы развертывания.
За последний год клиентов с виртуальными рабочими столами стало больше, и мы собаку съели на их настройке и оптимизации. Сегодня расскажу, на что обратить внимание при планировании инфраструктуры виртуальных рабочих столов. Эти кейсы помогут улучшить пользовательский опыт и не дадут внедрению провалиться.
Надеюсь, список будет полезен как при организации самостоятельного развертывания инфраструктуры, так и при выборе поставщика услуги. Рассматривать финансовые затраты из-за разброса вариантов не стал, остановлюсь на технических и организационных моментах.
Прим. перев.: в конце прошлого года Anne LoVerso — инженер из VMware Pivotal Labs — опубликовала развернутое сравнение Kubernetes с… океанариумом. Эта небольшая статья с наглядными иллюстрациями и аналогиями ориентирована на тех, кто впервые знакомится с K8s, и призвана упростить их самое первое погружение в дебри океана… оркестратора.
Kubernetes объявил Docker устаревшим и планирует прекратить его использование примерно через год, в версии 1.22 или 1.23. Эта новость вызвала много вопросов и непонимания. В блоге Kubernetes появилось целых две статьи, разъясняющих смысл записи в Changelog (раз и два). Если все обобщить, то для разработчиков (те, которые Dev) ничего не меняется — они все так же могут продолжать использовать docker build для сборки своих контейнеров, а вот для инженеров, ответственных за эксплуатацию кластера (Ops), пришла пора разобраться и освоить несколько новых инструментов.
Сравнение трех самых популярных Managed Kubernetes платформ.
Kubernetes уже стал синонимом оркестрации контейнеров, поэтому каждый облачный провайдер активно разрабатывает под него свои управляемые сервисы. Чтобы выбрать один из них, нужно как следует все изучить и учесть много факторов.
В статье сравним Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS).
Вертикальное автомасштабирование подов (Vertical Pod Autoscaling) — одна из крутых функций Kubernetes, которую недостаточно часто используют. И на это есть серьезные причины.
Kubernetes был создан для горизонтального масштабирования, и изначально вертикальное масштабирование подов не казалось очень-то хорошей идеей.