Dhall — программируемый язык для создания конфигурационных файлов различного назначения. Это Open Source-проект, первый публичный релиз которого состоялся в 2018 году.
Как и всякий новый язык для генерации конфигурационных файлов, Dhall призван решить проблему ограниченной функциональности YAML, JSON, TOML, XML и других форматов конфигурации, но при этом оставаться достаточно простым. Язык распространяется всё шире. В 2020-м году представили его bindings, сделанные специально для Kubernetes.
Этой ночью официально выпустят новую версию Kubernetes — 1.23. Рассказываем о самых интересных нововведениях (alpha), а также о некоторых фичах, которые перешли на уровень выше (beta, stable).
Для подготовки статьи использовалась информация из таблицы Kubernetes enhancements tracking, Читать полностью »
werf — это CLI-утилита с открытым кодомЧитать полностью »
Андрей Квапил (kvaps) — Solutions Architect в компании Флант. Путь в ИТ он начал с подработки эникейщиком во время учебы в школе. А сейчас создает платформы для автоматического управления инфраструктурой, участвует в open-source-сообществе, пишет статьи и выступает на конференциях. Поговорили с Андреем о его карьере в ИТ, переезде в Чехию и выступлениях на конференциях.
Андрей — один из спикеров VK Kubernetes Conference, которая пройдет 9 декабря 2021 года.
— Первый компьютер в нашей семье появился у деда — он работал профессором в МГУ. Это был Pentium 1 133 Mhz с 32 Мбайт памяти, еще с кнопкой Turbo. Мои старшие братья часто играли на нем в Larry, а мне не разрешали. Но меня тогда интересовал не сугубо развратный подтекст игры, а то, насколько широко она использует возможности компьютера. Звуковых карт тогда еще не было, но музыка проигрывалась через спикер. Мне это показалось крутым: компьютер играет музыку, ничего себе!
Читать полностью »
Недавно компания Datadog, разработчик одноименной системы мониторинга, представила свой обновленный отчет «10 трендов использования контейнеров в реальном мире». Авторы исследования проанализировали полтора миллиарда контейнеров, развернутых тысячами компаниями-клиентами Datadog.
Привет! Я Алексей, старший системный администратор ЮMoney. Так уж вышло, что я — главный по Куберу в компании. Поэтому когда меня попросили рассказать, как мы создавали сервис Kubernetes и что у нас в итоге получилось, уговаривать меня долго не пришлось.
Зачем вообще компании может понадобиться оркестрация контейнеров? Когда приложений немного, то и задача такая, как правило, не стоит. Администраторы знают каждое приложение в лицо, живут они на небольшом числе серверов. В такой ситуации ресурсы обычно выделяются вручную.
Недавно мы помогли нашему клиенту Adapty перенести инфраструктуру с managed-сервисов AWS. Теперь она размещена в Kubernetes-кластере на обычных инстансах другого облачного провайдера, но ее можно легко мигрировать в другой ЦОД в случае необходимости. Этот бизнес-кейс во многом показательный: Adapty удалось минимизировать зависимость от поставщика, снизить инфраструктурные затраты на 50%, а также снять некоторые технические ограничения по масштабированию и оптимизации своих приложений.
Эффективное использование машинного обучения — сложная задача. Вам нужны данные. Вам нужен надёжный конвейер, поддерживающий потоки данных. И больше всего вам нужна высококачественная разметка. Поэтому чаще всего первая итерация моих проектов вообще не использует машинное обучение.
Об этом говорю не только я.
Догадайтесь, какое правило является первым в 43 правилах машинного обучения Google?
Правило №1: не бойтесь запускать продукт без машинного обучения.
Машинное обучение — это здорово, но для него требуются данные. Теоретически, можно взять данные из другой задачи и подстроить модель под новый продукт, но она, скорее всего, не справится с базовыми эвристиками. Если вы предполагаете, что машинное обучение придаст вам рост на 100%, то эвристика даст вам 50%.
В этой статье я хотел бы рассказать о том, как мы меняли подход к оркестрации на нашем стартап-проекте, зачем мы это делали и какие проблемы по дороге решали. Претендовать на уникальность эта статья вряд ли может, но все же думаю, что она может быть кому-то полезна, так как в процессе решения задачи материал собирался нами с приличным скрипом.
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
