Поделюсь с коллегами практикой создания Docker-сборок на базе Spark разных версий, которые могут запускаться как Spark Kubernetes Executors для параллельного выполнения Spark-задач в кластере.
В нашем конкретном случае сборки включают Pyspark и Cassandra Connector, однако вы можете использовать этот материал как набор практических примеров, чтобы сконструировать собственные Docker-сборки для Spark на другом стеке или с другими приложениями.
Всем привет! Для своей первой статьи я решил выбрать проблему, с которой сам столкнулся при изучении Java и попытке упаковки приложения в докер-контейнер. К сожалению не нашел ни одной исчерпывающей статьи, как это делать, поэтому решил написать свою.
Всем привет, меня зовут Аббакумов Валерий.
Я Python разработчик, в основном занимаюсь бэкэндом веб приложений и каждый раз когда дело доходит до разворачивания нового проекта по моей щеке начинает течь слеза.
Думаю, никто не будет спорить с тем, что локальное разворачивание нового проекта может вызвать неограниченное количество проблем. В данной статье я хочу представить выстраданную годами структуру проекта и организацию его окружения, которые помогают избежать большей части проблем, связанных с локальным разворачиванием проекта.
Старайтесь всегда использовать многоэтапную сборку, для создания более компактных Docker образов. Давайте, рассмотрим на примере, как многоэтапная сборка позволяет значительно уменьшить размер Docker образа. В качестве примера, мы будем использовать простое веб-приложение на Golang:
package main
import (
"fmt"
"log"
"net/http"
)
func main() {
http.HandleFunc("/", HelloServer)
fmt.Printf("Starting server at port 8080n")
if err := http.ListenAndServe(":8080", nil); err != nil {
log.Fatal(err)
}
}
func HelloServer(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello world")
}
Сначала, соберем Docker образ в один этап:
Читать полностью »Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше так никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.
Часть этого пути — сборка Docker-образа. Иногда сборка длится минуты, иногда — десятки минут, что сложно назвать нормальным. В данной статье возьмём простое приложение, которое упакуем в образ, применим несколько методов для ускорения сборки и рассмотрим нюансы работы этих методов.
werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Как и обещали, выход версии v1.0 знаменовал начало добавления в werf новых возможностей и пересмотра привычных подходов. Теперь мы рады представить релиз v1.1, который является большим шагом в развитии и заделом на будущее сборщика werf. Версия доступна на данный момент в канале 1.1 ea.
Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте.Читать полностью »
Werf — это GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Werf поддерживает сборку образов приложения с помощью Dockerfile или собственного встроенного сборщика (на основе синтаксиса YAML, с поддержкой Ansible и инкрементальной пересборки на базе Git). Для доставки приложения используется формат конфигурации, совместимый с Helm. Код приложения, конфигурация собираемых образов и конфигурация выката приложения хранятся в одном Git-репозитории.
Долгожданный стабильный релиз 1.0 — это законченная по функциям базовая версия утилиты (точный номер версии первого стабильного релиза — это 1.0.6). В базовой версии werf поддерживает полный цикл доставки приложения и его сопровождения. Это включает в себя сборку образов приложения, деплой в Kubernetes, очистку неиспользуемых образов.Читать полностью »
