как деплоить новый go в старые дистрибутивы?

systemd-nspawn.

Но в контейнере go в упор не видит модули, какой WORKDIR не используй.

Что именно имеется ввиду?

Хотелось бы докеризовать — это более правильный путь. Но в контейнере go в упор не видит модули, какой WORKDIR не используй.

Просто, чтобы отсечь варианты:

1. Го 1.18+?
2. Скопирован директорий вместе с go.work?
3. Скопированы и go.mod тоже, всё необходимые?
4. Выполнено go mod download?
5. Переменные окружения не вносят неразберихи?

Как то так.

CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go install -ldflags «-w -s -extldflags ‘-static’»

Так ты в докере пытаешься компилить модули из go в native? А кросс компиляцию не пробовал? Чтобы статически один бинарник собрать и положить уже его в докер контейнер. Или собрать статически на новом линукс дистре, и на нём контейнизировать один статический файл исполняемый для более старых версий

прост брал докер го на базе старого дебиана, биндил в него исходники проекта через -v и в нем собирал бинарник

Но в контейнере go в упор не видит модули, какой WORKDIR не используй.

Ты что-то делаешь не так, видимо.

GLIBC 2.32 – это 2020 год. За три года-то можно уже обновиться, не?

Как вариант, собери такую же glibc как там, кинь куда-нибудь в CI и подсунь линкеру ключи чтобы с ней линковал.

https://tldp.org/HOWTO/Glibc2-HOWTO-6.html

panic: Binary was compiled with 'CGO_ENABLED=0', go-sqlite3 requires cgo to work. This is a stub

Грабли. Надо ещё чего-то дособирать и хз насколько это затянется.

Не, плохая идея. Допустим, бинарник в докере запускается. Но как тогда организовывать CI/CD или просто на dev сервере собирать? Пусть лучше прямо в докере собирается. А со статикой я сильно натрахаюсь.

Прошёлся по чек-листу, в итоге оказалась банальность — прописал неправильные пути, поэтому файлы не копировались. А правильно вот так:

FROM golang:1.20.6

COPY . /src/
COPY ./configs/.env /app/

WORKDIR /src/cmd/main
RUN go build -o /app/main

WORKDIR /app
EXPOSE 8000
ENTRYPOINT [ "/app/main"]

Теперь деплоится как положено.

можно пробовать modernc.org/sqlite он чисто на go

написать примерное так go.mod

replace github.com/mattn/go-sqlite => modernc.org/sqlite

и по идее должно работать.

Вы перепутали понятия сборка и разворачиание(деплой).

У вас тут происходит сборка приложения в докер-контейнере и поэтому непонятно, при чём тут деплой.

Сборка — часть деплоя. Может, не совсем верно выразился, но и не полностью ошибочно.

Сборка — часть деплоя.

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

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

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

А ещё IT не ограничивается кровавым энтерпрайзом с его кубернетесами на миллиард инстансов. Есть много маленьких проектов, которые деплоятся на 1 сервер, в них сборка всегда часть деплоя.

Это если есть несколько серверов, где один как раз отвечает за CD. Или если это открытый проект. Тогда да, правильный путь — собрать какой-нибудь докер образ, который все потом просто накатят. Выше ответил, почему это не всегда так.

Даже в маленьком проекте это очень полезно. Представь, у тебя есть поделка на Го. Ты закатил новую версию на сервер. Она оказалась сломана, ты пытаешься откатиться и... старая версия уже не собирается, так как Гитхаб (Maven Central в случае Java) прилег. Все! ты приехал. Сервер лежит.
Понятно, что в жизни не всегда следуют правилам и сознательно упрощают процессы, выбрасывают какие-то шаги. Трудовых ресурсов на это часто не хватает. Но это разные процессы, как ни крути.

Не обязательно удалять старый образ докера или старые билды. Обычно это делается руками, но и сценарий CI можно так написать, чтобы последние n версий оставались.

Ну так это уже и делает сборку и развертывание разными вещами. :)

Перезапуск сервиса — это деплой? Какое-то очень условное разделение.

На жабаскрипт переписать

Обычно есть два разных процесса:

1. Сборка, в результате которой из исходника собирается некий артефакт.
2. Развёртывание, артефакт доставляется из репозитария в нужное окружение.

Их, конечно, можно проводить последовательно один за одинм, но это всё равно два разных процесса.

Да не перезапуск, а развертывание предыдущей сборки.

Да хоть у себя на локалхосте собирай и разворачивай. Одним процессом это всё равно не станет. )

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

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

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

В разрезе приложений написаных на GO:

• Сборка: компиляция бинарника
• Деплой:
  • Копирование бинарника
  • Запуск бинарника

В разрезе докер-образов:

• Сборка: docker build -t <tag> .
• Деплой: docker run <tag>

Используй мультистейдж-сборку.

https://ru.werf.io/guides/golang/200_real_apps/010_basic_app.html

Раскрою мысль.

1. У тебя в докер-файле описан сборочный контейнер и продовый.

• В сборочном все, что нужно для сборки: го, либы и прочая хрень. В него копируешь или монтируешь сорцы и собираешь бинарник
• В этом же докерфайле копируешь полученный артефакт (бинарник собранный) в чистый контейнер, в котором он будет запускаться. Если надо, предварительно туда же ставишь что-то нужное из библиотек или хз, что там тебе надо.

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

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

Лучше тогда доку от докера https://docs.docker.com/language/golang/build-images/#multi-stage-builds

Ну да, или так.