Что такое теги сборки?

Тег сборки - это комментарий в начале go-файла, который указывает компилятору, как стоит собирать этот конкретный файл.

Например, при таком теге файл будет включен в сборку только в том случае, если компиляция выполняется под линукс (GOOS=linux)

// +build linux

package mypackage
...

Тег сборки должен быть расположен в начале файла, а после строки с ним должна быть пустая строка.

Также можно использовать оператор отрицания !. Таким образом, файл с тегом // +build !linux будет включен в сборку на всех платформах, кроме linux.

В тегах может быть несколько условий. Если условия расположены на одной строке, то они комбинируются через оператор OR. А если на нескольких строках, то через AND.

// +build linux darwin
// +build amd64

package mypackage
...

В примере выше файл будет включен в сборку только под linux/amd64 или darwin/amd64 платформы.

Разделение тестов

Через теги сборки можно разделять разные виды тестов.

Рассмотрим 2 файла тестов:
myfile_test.go:

package mypackage

import "testing"
...

myfile_integration_test.go:

// +build integration

package mypackage

import "testing"
...

В файле myfile_test.go будут расположены unit тесты, а в myfile_integration_test.go - интеграционные (более медленные).

Поэтому при запуске тестов через go test запустятся тесты только из myfile_test.go. А если нужно запустить тесты из myfile_integration_test.go, то надо добавить флаг —tags.

go test --tags=integration

Важно понимать, что при запуске go test --tags=integration так же запустятся unit тесты. Чтобы такого не произошло, надо добавить отрицание в теги сборки unit тестов.

myfile_test.go

// +build !integration

package mypackage

import "testing"
...

Итог

Есть несколько причин такого разделения тестов:

1. Интеграционные тесты значительно медленней unit тестов, поэтому их обычно стоит запускать только после успешного запуска unit тестов
2. Компиляция под разные платформы
3. Smoke тесты, запускаемые на production приложение после деплоя.

Источник: https://mickey.dev/posts/go-build-tags-testing/

Если коротко:

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

Посмотреть текущую конфигурацию:

~ ❯ go env GOPROXY
https://proxy.golang.org,direct

В переменной GOPROXY будут указываться источники через запятую, откуда go будет пытаться скачать необходимый пакет. Если первый источник ответит 4xx, то go попробует скачать пакет по следующей ссылке.

Direct указывает, что код надо загрузить по прямой ссылке из VCS. То есть ровно по той ссылке, как пакет импортируется в коде.

Однако, загружать пакеты с VCS может быть не всегда безопасно.

Кто-то может внести вредоносный код в новых коммитах, или даже если вы строго зафиксировали версию пакета, с которым хотите работать, злоумышленник может изменить текущую версию кода через  git push --force

Сейчас по умолчанию в GOPROXY устанавливается https://proxy.golang.org как прокси и работает как кеш. То есть если в proxy.golang.org нужного пакета не найдется, то он его скачает и сразу же отдаст нам. Этот кеш гарантирует, что код не будет изменен.

Источники:

https://golang.org/ref/mod#goproxy-protocol

https://jfrog.com/blog/why-goproxy-matters-and-which-to-pick/

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

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

Ниже описаны основные уровни логов и причины их использовать:

ERROR

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

Например:  Внешний платежный шлюз перестал отвечать на наши запросы

WARNING

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

Например:  На наш запрос не ответил внешний платежный шлюз. Дальше retry система попробует повторить запрос еще несколько раз. И если шлюз так и не ответит, то упадет ошибка ERROR

INFO

Произошло изменение в системе или в какой-то сущности.

Например:

1. Система поднялась на порту 8080

2. создан новый пользователь

3. вывод по cron задачу

DEBUG

Служит для отладки приложения при разработке, или в случае, когда надо поймать что-то на проде.

Например: текущее значение какой-то переменной

TRACE

Такой уровень логов нужен, чтобы отслеживать запросы внутри приложения.

Например:

1. Пришел запрос на url /home
2. Завершили обрабатывать запрос на /home за 0.5 секунд
3. Начали/завершили обрабатывать метод

Источник: https://reflectoring.io/logging-levels

1. Состояние системы на момент запуска теста
2. Событие, которое изменяет состояние системы
3. Результат - то, что должно произойти/измениться

Для удобства предлагается разделить эти комментариями, чтобы не пытаться понять все через код.

Обратите внимание, что assert'ы выполняются только в третей части теста.

Названия тестовых методов является продолжением фразы:  "Что случается, когда ..."

Источник: https://matthiasnoback.nl/2021/09/write-unit-tests-like-scenario

Чтобы облегчить образ, надо использовать multistage build. Это когда сначала все собирается в один образ, а потом результаты сборки копируются в другой. А инструменты сборки и все лишнее не копируются.

Так итоговый образ получился размером 4.3MB

jjjjj