Привет, Хабр! представляю вашему вниманию перевод статьи «Go, gRPC and Docker» автора Mat Evans.

Существует множество статей о совместном использовании Go и Docker. Создавать контейнеры, способные взаимодействовать с клиентами и между собой, очень легко. Далее следует небольшой пример того, как это делается на базовом уровне.

Здравствуйте, коллеги.

Сегодня на ваш суд предлагается перевод статьи Тугберка Угурлу (Tugberk Ugurlu), который взялся в сравнительно небольшом объеме изложить принципы проектирования современных софтверных систем. Вот что автор сообщает о себе в сухом остатке:


Поскольку решительно невозможно охватить в хабростатье такую колоссальную тему, как архитектурные паттерны + паттерны проектирования по состоянию на 2019 год, рекомендуем не только сам текст господина Уруглу, но и многочисленные ссылки, которые он в нем любезно расставил. Если вам понравится — опубликуем и более узкоспециальный текст о проектировании распределенных систем.

Цель этого поста: показать технику отладки в debian/ubuntu, связанную с "поиском первоисточника" в системном конфигурационном файле.

Тестовый пример: после долгих издевательств над tar.gz копией установленной ОС и после её восстановления и установки апдейтов мы получаем сообщение:

update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/foobar-swap)
I: Set the RESUME variable to override this.

Цель: понять, откуда это значение (U1563304817I0) пришло и как его правильно поменять. Это первый попавшийся пример, не особо интересный сам по себе, но удобный, чтобы показать практические методы работы с Linux.

Шаг номер 1: Откуда пришёл RESUME?

Этот пост — мой топ самых распространенных ошибок, которые встречались мне в Go-проектах. Порядок не имеет значения.

Неизвестное значение Enum

Давайте взглянем на простой пример:

type Status uint32

const (
	StatusOpen Status = iota
	StatusClosed
	StatusUnknown
)

Здесь мы создаем энумератор с помощью iota, что приведет к такому состоянию:

StatusOpen = 0
StatusClosed = 1
StatusUnknown = 2

Всегда хочется придумать что-то новое и нужное в своём сервисе. Особенно, если этот сервис любят пользователи. Но откуда брать идеи? Как выделить приоритетные? И как быстро довести идею до продукта, не потеряв ничего важного по пути?

Меня зовут Александр, я руковожу одной из групп разработки интерфейсов в Яндекс.Маркете. Сегодня я расскажу читателям Хабра о нашем опыте решения этих задач. Также рассмотрим пример доставки фичи в продакшн.

Привет, Хабр! Предлагаю вашему вниманию перевод статьи основателя сервиса Meetspaceapp Nick Gauthier «Building Minimal Docker Containers for Go Applications».

Время чтения: 6 минут

Существует множество, как официальных, так и поддерживаемых сообществом контейнеров для различных языков программирования (включая Go). Но эти контейнеры могут быть довольно большими. Давайте сперва сравним стандартные методы создания контейнеров для Go-приложений, а затем я покажу способ создания крайне маленьких статических контейнерезированных Go-приложений

Часть 1: Наше «приложение»

Для тестирования нам потребуется какое-нибудь маленькое приложение. Давайте будем фетчить google.com и выводить размер HTML.

package main

import (
    "fmt"
    "io/ioutil"
    "net/http"
    "os"
)

func main() {
    resp, err := http.Get("https://google.com")
    check(err)
    body, err := ioutil.ReadAll(resp.Body)
    check(err)
    fmt.Println(len(body))
}

func check(err error) {
    if err != nil {
        fmt.Println(err)
        os.Exit(1)
    }
}

Если мы запустимся, то получим только какое-то число. У меня вышло около 17К. Я целенаправленно решил использовать SSL, но причину объясню позднее.

История по оптимизации образов для java приложений началась с выхода статьи в блоге спринга — Spring Boot in a Container. В ней обсуждались различные аспекты по созданию docker образов для spring boot приложений, в том числе и такой интересный вопрос, как уменьшение размеров образов. Для наших команд это было актуально в силу ряда причин, поэтому мы решили применить это решение к нашим приложениям.

Как это часто бывает, не все взлетело с первого раза, возникли нюансы с многомодульными проектами и попыткой гонять все это на CI системе, так что в данной статье вы найдете решение этих проблем.

Целью оптимизации является сокращение разницы между получаемыми образами от сборки к сборке, что дает хороший результат в процессе непрерывной поставки, так что если вас интересует минимизация размера образа как такового, можете обратиться к другим статьям на хабре.

Если причины, зачем вообще что-то делать с многометровым бутовым приложением перед помещением его в образ, вам объяснять не надо, можете сразу перейти к описанию подхода по оптимизации. Если вы успели ознакомиться со статьей из спрингового блога, можете перейти к решению найденных проблем.