выглядит презабавно, почти так же как react-starter-kit, где multi-staget build Docker делают через JS :)
Ok, тогда вопросы такие, как вы разруливаете разные типы билдов? — билд для qa, staging, production
Похоже вы не пользуетесь beta дистрибуцией такой как Firebase. Почему?
Как вы автоматизировали выгрузку в Testflight и автозаполнение Security Compliance там?
Какой у вас flow в git чтобы не тормозить разработку? т.к. Apple в Testflight может выдавать аппрув на билд до недели
Нигде не вижу использования Fastlane Match, вы его не пользуете или?
Как насчёт whitelabeling?
FROM node:lts-alpine AS build
WORKDIR /build
COPY . .
ARG VUE_APP_BASE_DOMAIN
ARG VUE_APP_ROLLBAR_TOKEN
ARG VUE_APP_ROLLBAR_ENV
RUN set -x && \
yarn install && \
yarn build
FROM nginx:stable-alpine
# for local builds; will be overrided by heroku
ENV PORT="80"
COPY --from=build /build/dist /usr/share/nginx/html
COPY nginx.conf /etc/nginx/nginx.conf
COPY entrypoint.sh /usr/bin/
RUN chmod +x /usr/bin/entrypoint.sh
# ignored for heroku
EXPOSE ${PORT}
ENTRYPOINT ["entrypoint.sh"]
CMD [ "nginx","-g", "daemon off;"]
entrypoint.sh
#!/bin/sh
set -xe
echo "DEBUG: Docker - entrypoint init"
echo "DEBUG: Nginx port is ${PORT}"
echo "DEBUG: changing port in config"
sed -i "s/CHANGEME_NGINX_PORT/${PORT}/" /etc/nginx/nginx.conf
# exec the container's main process (what's set as CMD in the Dockerfile).
exec "$@"
само собой, я же не оформлял это как баш-скрипт, который всё сам сделает, просто один читатель попросил проверить, работает ли оно на данный момент. Я тупо history в баше скопировал, добавил немножко комментов и всё
Вы меня пардоньте, но он не работает.
Я добавляю сайт — система меня выкидыват на loginpage. Я об этом отписывался в отзывах, но ничего с тикетом не сделали :)
ну, здесь зачастую люди и делятся велосипедами. Вариант имеет место быть и ваш тоже, мне как-то привычнее и удобнее было сделать именно так.
Велосипед с квадратными колёсами едет немного с бОльшим усилием, а тут по «усилиям» — производительности, ресурсам, скорости загрузки вообще ничего не изменится.
ну, у меня после такого теста просто нет сомнений, что это действительно так:
1. Итак, представим, что мы такие всё зашифровали и у нас сейчас в /etc/default/grub GRUB_ENABLE_CRYPTODISK=n, далее мы делаем grub-install /dev/vda и вот, что происходит, ololo.efi генерится заново и т.д.
Потом мы грузимся(пытаемся) и, так как grub не видит конфига он тупо входит в grub-rescue или как там оно называется.
2. Сразу после этого, мы с live-cd заходим, открываем контейнер, бла-бла-бла, заходим в chroot и меняем GRUB_ENABLE_CRYPTODISK=y в /etc/default/grub, далее опять делаем grub-install /dev/vda, и тут получаем уже новый ololo.efi, который уже будет пытаться найти и запросить пароль для расшифровки luks.
‘GRUB_ENABLE_CRYPTODISK’
If set to ‘y’, grub-mkconfig and grub-install will check for encrypted disks and generate additional commands needed to access them during boot. Note that in this case unattended boot is not possible because GRUB will wait for passphrase to unlock encrypted container.
и я думаю, что нет способа «generate additional commands needed to access them during boot» без перекомпиляции этого бинарника.
ок, давайте разложим для понимания тогда.
У нас есть 3 «инстанции», куда обращается GRUB, записывает и чем оперирует.
1. «последовательность загрузки в nvram». По сути это некая область памяти на мат. плате, где написать «шо и куда и последовательно как»
2. Начало диска — как обратная совместимость с обычной BIOS загрузкой (первые 4** байт, кто-то говорит 512, где-то написано, что до 2 мегабайт может занимать) — не суть
3. /boot/efi — раздел fat32 EFI — туда кладётся исполняемый бинарник — приложение UEFI — совместимое.
Моя догадка в том, что бинарник всё-таки меняется и, собственно он(исполняемый файл EFI, выполняясь, уже имеет инструкцию искать и предлагать расшифровать).
@devpew
Это уже есть на офф вики https://wiki.archlinux.org/title/Dm-crypt/Encrypting_an_entire_system
Это уже есть на хабре https://habr.com/ru/post/420081/
довольно странная статья, выглядит как компиляция всего со всем и ещё немножко тёмной материи.
Прокомментировать это можно только этим:
```
Поживу я, воля божья, у румын
Говорят, они с поволжья, как и мы
```
Добро пожаловать)
Хочешь — оставайся, хочешь — уезжай. Всем насрать же, что ты со своей жизнью делаешь. Выбор-то твой.
Хабр превратился в срач-портал.
я хз, но оно на github pages есть, если всё правильно настроено. Достаточно просто инструкцию почитать. Почему вам этого не хватало?)
Пруф
Ну, нет, можно и мастер оставить — никаких проблем. Пруф
Мне кажется, что можно было более информативно раскрыть что это такое и с чем это едят, чем сделано в статье
Ok, тогда вопросы такие, как вы разруливаете разные типы билдов? — билд для qa, staging, production
Похоже вы не пользуетесь beta дистрибуцией такой как Firebase. Почему?
Как вы автоматизировали выгрузку в Testflight и автозаполнение Security Compliance там?
Какой у вас flow в git чтобы не тормозить разработку? т.к. Apple в Testflight может выдавать аппрув на билд до недели
Нигде не вижу использования Fastlane Match, вы его не пользуете или?
Как насчёт whitelabeling?
Dockerfile
entrypoint.sh
Я добавляю сайт — система меня выкидыват на loginpage. Я об этом отписывался в отзывах, но ничего с тикетом не сделали :)
по умолчанию не прописан --color, в RHEL по крайней мере
все эти gaa и прочее это, как уже выше заметили, верный способ выстрелить себе в ногу, да и не такая уж и значительная экономия времени, надо сказать.
т.е. это в разы удобнее чем
? Особого смысла не вижу
полезнее был бы даже алиас
на
Да и вообще сам синтаксис git достаточно простой, чтобы не страдать никакими алиасами, ну, мне так кажется.
Хотя devops это методология, которая применима почти где угодно.
Велосипед с квадратными колёсами едет немного с бОльшим усилием, а тут по «усилиям» — производительности, ресурсам, скорости загрузки вообще ничего не изменится.
к тому же… чего ждать, если можно тупо почитать:
www.gnu.org/software/grub/manual/grub/grub.html
и я думаю, что нет способа «generate additional commands needed to access them during boot» без перекомпиляции этого бинарника.
У нас есть 3 «инстанции», куда обращается GRUB, записывает и чем оперирует.
1. «последовательность загрузки в nvram». По сути это некая область памяти на мат. плате, где написать «шо и куда и последовательно как»
2. Начало диска — как обратная совместимость с обычной BIOS загрузкой (первые 4** байт, кто-то говорит 512, где-то написано, что до 2 мегабайт может занимать) — не суть
3. /boot/efi — раздел fat32 EFI — туда кладётся исполняемый бинарник — приложение UEFI — совместимое.
Моя догадка в том, что бинарник всё-таки меняется и, собственно он(исполняемый файл EFI, выполняясь, уже имеет инструкцию искать и предлагать расшифровать).