применительно к ангуляру? или про что?

статический сервер- это что?

сервить через nginx? это как, чего?

ну, запихнул бандл в docker image, в котором есть nginx, и наружу смотрит порт 8080 от nginx, на котором только твоя статика. nginx быстрее node

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

Всем привет, подскажите, пожалуйста, как правильно организовать билд и деплой ангуляр-приложения с докером. В простейшем случае - 2 версии приложения - dev и prod. Различаются режимами сборки и обращаются к различным серверам через прокси в nginx, ну и выкатываться будут соответственно на различных серверах. Просто я у себя создал 3 Dockerfile: - Dockerfile.local - Dockerfile.dev - Dockerfile.prod В них различается режим билда приложения на уровне ангуляра (dev и prod сборки), и подсовываются различные конфиги для nginx (в них различаются прокси). Из консоли я могу вызывать команду docker build -t webapp-wms . --file='Dockerfile.dev' и тогда соберется нужный образ. И я думал, что в npm-скрипт можно запихнуть эту команду, вроде: "build-dev-image": "docker build -t webapp-wms-dev . --file='Dockerfile.dev'" , но нет, при вызове npm-скрипта вываливается следующая ошибка unable to prepare context: unable to evaluate symlinks in Dockerfile path: GetFileAttributesEx C:\Users\koolikov.av\Documents\projects\webapp-WMS\'Dockerfile.dev': The system cannot find the file specified. И я могу билдить образ через npm-скрипт, но только если буду удалять расширение на нужном докерфайле .dev, .prod или .local, а это уже сильный колхоз. А хотелось бы просто, запускать билд нужного образа одной командой, которая включала бы в себя : - удаление старого образа - билд нового образа (dev, prod, local) - выставление тэга этому образу для гитлаба - пуш образа с проставленным тэгом в гитлаб В общем, если кому не сложно, подскажите, пожалуйста, с помощью какого инструментария это все проворачивается и как вообще процесс должен быть организован? потому что мой вариант пока явный колхоз

во-первых - мультистейдж во-вторых - можно ARG передавать переменные внутрь контейнера на стадии сборки и в зависимости от этого что-то делать

да, жать там, или в cdn отдавать / подменять

ну, ты можешь в докер слое его держать

Ну а как это между билдами делать?

во-первых - мультистейдж во-вторых - можно ARG передавать переменные внутрь контейнера на стадии сборки и в зависимости от этого что-то делать

или подразумевается что делаем билд на одном и том же сервере?

и как тогда он понимает наличие кеша когда мы запускаем docker build —target=cache?

по идее можно сделать билд кеш имиджа, и в нем же билдить кеш. то есть на момент запуска docker build в from имидже уже будет старый кеш

если условные конструкции в dockerfile возможны, то это решит все проблемы

я в докере вообще не разбираюсь - я фронтенд, и я думал, что в докерфайле нельзя исполнять какие-то условия. Т.е по уму, конечно было бы прописать скрипт 'build-dev-image': docker build -t webapp-wms-dev . ARG MODE=DEV, и в зависимости от него в инструкции Dockerfile сделать нужные манипуляции. Что-то вроде: FROM node:8-alpine as buildContainer COPY . /app WORKDIR /app RUN npm install IF (MODE == 'LOCAL' || MODE == 'DEV') { RUN npm run build } ELSE { RUN npm run build } FROM nginx:alpine COPY --from=buildContainer /app/dist/webapp-WMS /app IF (MODE == 'LOCAL') { COPY --from=buildContainer /app/deploy-configs/local/nginx.conf /etc/nginx/nginx.conf } IF (MODE == 'DEV') { COPY --from=buildContainer /app/deploy-configs/dev/nginx.conf /etc/nginx/nginx.conf } IF (MODE == 'PROD') { COPY --from=buildContainer /app/deploy-configs/prod/nginx.conf /etc/nginx/nginx.conf } COPY --from=buildContainer /app/mime.types /etc/nginx/mime.types COPY --from=buildContainer /app/gzip.conf /etc/nginx/gzip.conf EXPOSE 9000/tcp

ты можешь сделайть лайфхак

просто изначально мультистейдж это не ответ для node_modules, .npm

спасибо, ребят, был убежден, что в докере нет условных конструкций никаких, от этого и подзакипел

RUN if [ "$argname" = "false" ] ; then echo 'false'; else echo 'true'; fi нашел такой пример, любая условная конструкция начинается с RUN? и еще и заканчивается каким-то fi

RUN исполняет bash магию, ты туда можешь пихнуть все что может bash

я бы все равно сделал dev/build контейнер и еще один в качестве деплоя

я бы все равно сделал dev/build контейнер и еще один в качестве деплоя

2. используй COPY

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

аналогичная история

+

Ребят, расскажите кто какую ci систему использует, там jenkins, teamcity или gitlab ci, просто интересна эта вещь)) И если не сложно, то почему именно это и выбрали

все

это не столь принципиальный вопрос. Из указанных трех проще начать с гитлаба

Свои раннеры - это к примеру какие?