Docker-образ для раздачи Single Page Application

Ссылка на s3 это как ссылка на внешнее апи или подключение к базе. Из-за этого сервис не приобретает state. Это stateless.

Подход с другой стороны
Сможете ли вы запустить 1кк контейнеров с общим PV? -> без дикого гемора нет (так себя ведут stateful)
Сможете ли вы запускать 1кк контейнеров с выкачиванием? -> да (так себя ведут stateless)

Docker-образ для раздачи Single Page Application

PV это уже stateful + PV нужен ReadWriteMany (я редко работаю с такими, может ReadOnlyMany, но вообще не сталкивался с ним), такие хранилища обычно медленные. Со скачиванием просто получается реаликация с мастером в виде s3.

Docker-образ для раздачи Single Page Application

Ссылка на выкачивание статики берется оттуда же, откуда ссылка на image. Разницы нет.

Конкретно про спор.
FROM registry.gitlab.com/base/docker-nginx:1.0
ADD ./public /usr/share/nginx/html/public
Такой вариант хороший, кроме выше описанной ситуации, когда нужно обновить в куче реп это одну строчку (в больших компаниях реал сложно). Но если маунтить конфиг, то редко нужно.

Касательно подхода с выкачиванием статики… я вспомнил зачем это ввел. Была идея написать k8s оператор, чтобы одним деплойментом nginx сервить всю статику, потому что печально наблюдать 100+ контейнеров nginx в кластере.

Docker-образ для раздачи Single Page Application

Я выше писал часть из этого...

• s3 я имею в виду s3 compatible storage, которое есть у всех приличных облаков или больших кластеров (ceph, minio, etc на своих серверах)
• ваш личный HA registry (3 копии) скорее всего будет использовать этот самый s3 как внешнее хранилище https://docs.docker.com/registry/storage-drivers/s3/
• версией image рулят DevOps парни, версией статики фронтендщики, разделение ролей и тп

У нас все, что касается разворачивание лежит в отдельном репозитории. Туда не могут лезть все. От команды конкретного проекта требуется только отдать артефакт. Будет это image или архив не так важно (фронтенщикам проще s3, мало кто хорошо умеет собрать образ).

PS Вместо s3 можно использовать артефакты CI/CD у gitlab или еще кого (они так же лежат обычно на s3 https://docs.gitlab.com/ee/administration/job_artifacts.html#s3-compatible-connection-settings). Тогда думать вообще про хранилище не нужно. Но у нас исторически напрямую.

Docker-образ для раздачи Single Page Application

Да, все так. В случае уязвимости еще можно всех напрячь и быстро перекатить, но если там ничего не горит, а поменять хочеться… то это будет изменяться месяцами (завести таску на все проекты в джире и ждать пока низкоприоритетная таска выполнится через все процессы, что вы описали).

Docker-образ для раздачи Single Page Application

Да, уволюсь завтра, экспертиза ниже плинтуса =)

Docker-образ для раздачи Single Page Application

Точка отказа s3? С отказом s3 откажет и registry (только если они не пользуются разными s3). high available registry всегда используют внешнее хранилище, s3 самое простое.

Docker-образ для раздачи Single Page Application

Я недавно знакомому отключил его для сайта Самары. Результат -100мс пинга. Бесплатно того не стоит.

Docker-образ для раздачи Single Page Application

Не всем нужен CDN, если клиенты из одного города, то это деньги на ветер. Нормальные CDN стоят дороже раздачи со своих серверов.

Docker-образ для раздачи Single Page Application

Ну есть некий docker.io/nginx:1.2.3 b 100500 его реплик. Обновили версию — обновились контейнеры, все логично.

У вас это
myregistry.com/myproject1:v2
myregistry.com/myproject2:v2
myregistry.com/myproject3:v2
myregistry.com/myproject4:v2
Которые from nginx:1.2.3 с разной статикой.

И если вам нужно внести правки в базовый образ или конфиг nginx для всех проектов, то это правка всех проектов и пересборка всех images (в большой компании с большим количеством проектов это затянется на месяца без острой необходимости)

Docker-образ для раздачи Single Page Application

Если оно не скачается, то и не запустится. А rolling update откатит все обратно. Точно так же новый image может быть недоступен. Распределенные registry работают поверх s3 кстати и говорить, что registry надежнее не совсем правильно.

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

PS s3 я имею в виду s3 compatible storage, которое есть у всех приличных облаков или больших кластеров (ceph, minio, etc)

Docker-образ для раздачи Single Page Application

Насчет второго пункта — там все тоже самое. Нет никакой разницы… передавать куда-то ссылку на image или ссылку на архив или ссылку на image+архив вместе.

Docker-образ для раздачи Single Page Application

У меня нет проблем с тем, чтобы хранить ссылку на архив вместо ссылки на image. А вот проблемы, когда у вас 20-50-100 контейнеров со статикой и их нужно обновить все, возникает постоянно.

Docker-образ для раздачи Single Page Application

• envsubst может работать как простой шаблонизатор по env переменным (без кучи кода с awk).
• самый лучший (ИМХО) контейнер для статики скачивает архив со статикой с s3 перед стартом (занимает секунды), а пересобирать вообще не нужно. Можно скачивать вместе с nginx конфигом, если меняется от проекта к проекту.
  
  • если используется оркестратор вроде k8s или nomad, то можно вообще не собирать свой образ, а просто в манифесте переписать /etc/nginx/nginx.conf и entrypoint с wget для стандартного образа.

wget -qO- $ASSETS_URL | tar xvz -C /srv
exec nginx

Статика редко весит больше 20-50мб в архиве. Поэтому скачивать перед стартом — малая кровь за такой простой подход.

Почему стоит использовать Svelte для своих веб-проектов

т9 подставил… Вот пример кода https://github.com/cultureamp/react-elm-components/blob/master/index.js#L19 Это проблема не только vue

Почему стоит использовать Svelte для своих веб-проектов

Там нужно брал ref, создавать руками createElement(div) и уже на этот див вещать vue.

Kubernetes за 3 дня. Просто о сложном

Обижаете nomad. Это лучшее решение, если катить в кластер нужно, но в команде 0-1 devops человека. Будет на порядок дешевле, проще и меньше инцидентов.

Проще не иметь ролей, чем криво настроенные.
Проще не использовать CNI, чем кое как ее запустить.
Проще писать только stateless и не ставить как попало условный rook одной командой, ради того, чтобы дать прогерам писать в /uploads вместо s3
И тп.

Куб офигенный, но он часто избыточен. Направление понятно… за куб занесут больше организаторам.

Настройка связки Nginx / LetsEncrypt в Docker Swarm

В связке с consul+nomad. Я ушел от кубера из-за излишней сложности (если нужно просто запустить сотню сервисов без политик, ролей и тп, то consul+nomad+traefik идеальная связка). Крутого kubectl очень сильно не хватает, но у меня 0 инцидентов с кластерами nomad после старта, чего не скажешь про кубопыт.

Настройка связки Nginx / LetsEncrypt в Docker Swarm

Traefik годится и для сложных случаев. Отличное решение с кучей батареек в коробке, уже год в проде.

6 ошибок в английских словах, которые жутко бесят нейтивов

Я не думаю, что они устаревают. Где-то удобнее и короче использовать then

doSomeAsyncAction.then(setData)

вместо

const data = await doSomeAsyncAction();
setData(data);

или

setData(await doSomeAsyncAction());

И если функция не должна возвращать промис, то нельзя ее делать async, придется лепить уродливое замыкание и еще один уровень на try вместо вызова .catch(captureError)

useEffect(() => {
  (async () => {
    try {
      const data = await ...
    } catch (err) {
      ...
    }
  })();
});

useEffect(() => {
  request(...).then(setData).catch(captureError);
});