Создание образа — Как создать и развернуть образ докера за 2 минуты

Git JavaScript

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

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

Сделать это

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

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

курс

предыдущая реализация

Способ реализации перед оптимизацией на самом деле очень простой, то есть в деплоймент платформе через git тянуть содержимое текущей ветки, а потом поpackage.jsonУстановка всех зависимостей, в процессеbuildУпакуйте, а затем создайте образ на платформе развертывания.После завершения сборки опубликуйте образ в контейнере через платформу.

преимущество: Не волнуйтесь, просто нажмите, и все готово

недостаток: Образ очень большой, релиз медленный, сборка медленная, при возникновении проблемы с сетью или платформой образ рискует не собраться, а стоимость экстренного ремонта очень высока.

Большинство реализаций онлайн

Раньше я запрашивал некоторые методы в Интернете, и некоторые из методов реализации, которые я нашел до сих пор,CI, а затем выберите соответствующую ветку для выполненияdockerОбраз создается и, наконец, помещается в соответствующий контейнер.

преимущество: Зеркальная конструкция не вызывает беспокойства и может быть установленаcache, уменьшить размер зеркала

недостаток: Плохая управляемость,githubИспользование проектаgitlab CIкогда, частоpushесть еще одинcommitКогда обновление задерживается, проект не может быть собран с первого раза, и разные ветки имеют разныеnpmнадо сделать пакетcacheуправляемость, высокие затраты на техническое обслуживание

мыслительный процесс

локальное моделирование

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

这里需要一部分的 docker 方面的知识，但是不多，也不难，docker 的安装方式，我就不讲了，大家自行百度

по местному исполнениюdockerЗаказ:

docker build -t local-test:2150 PATH(自己当前项目目录)

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

Просмотр информации об изображении локально

После того, как образ собран нормально, мы можем найти текущий собранный образ локально:

docker images

Затем мы находим текущий созданный локальный образ и позже можем увидеть размер нашего текущего образа:

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

Запустите Docker-контейнер локально

в контейнер:

docker run -it local-test:2150 /bin/bash

Просмотр всех размеров файлов текущего изображения:

cd /
du -d1 -h

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

посмотриcode:

Одинnode_modulesСовершенно бесполезно, можно убить.

есть еще один./usrПапки, занимающие 1.2G, тоже в похожей ситуации, поэтому содержимое здесь не учитывается.

На самом деле, самое главное в зеркалировании заключается в том, чтоnginxа такжеbuildПослеdistПапки и большинство других содержимого, бесполезны и могут быть удалены. Мы, вероятно, знаем, откуда приходит проблема.

如果可以发现问题的本质，那就不是问题，是阅历 - 热情的刘大爷

Оптимизировать докерфайл

Давайте посмотрим на мой dockerfile перед оптимизацией:

FROM debian:9

RUN echo \
  deb http://mirrors.aliyun.com/debian/ stretch main non-free contrib\
  deb-src http://mirrors.aliyun.com/debian/ stretch main non-free contrib\
  deb http://mirrors.aliyun.com/debian-security stretch/updates main\
  deb-src http://mirrors.aliyun.com/debian-security stretch/updates main\
  deb http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib\
  deb-src http://mirrors.aliyun.com/debian/ stretch-updates main non-free contrib\
  deb http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib\
  deb-src http://mirrors.aliyun.com/debian/ stretch-backports main non-free contrib\
  > /etc/apt/sources.list

RUN apt-get update && apt-get -y upgrade
RUN apt-get install -y git-core curl build-essential
RUN curl -sL https://deb.nodesource.com/setup_10.x | bash -
RUN apt-get install -y nodejs
RUN npm config set registry https://registry.npm.taobao.org

RUN mkdir /code
ADD . /code
WORKDIR /code

RUN npm install
RUN npm run build:test

RUN cp -fr /code/dist/ /usr/share/nginx/html/
COPY nginx/prod.conf /etc/nginx/nginx.conf

EXPOSE 80

STOPSIGNAL SIGTERM

CMD ["nginx", "-g", "daemon off;"]

Посмотрите на содержание, на самом деле, то, что мы должны беспокоиться, это не так много, мы должны сделать, это поставитьbuildхороший мешок, положить его в/usr/share/nginx/html/, затем поставьтеnginxнастроить в/etc/nginx/nginx.confСреди них затем настройте порт, запуститеnginx.

Оптимизированный файл докеров

После удаления вышеперечисленных вещей я обнаружил, что мне все еще нужноbuild, в это время я придумал способ обгона в повороте: местныйbuild

FROM debian:9

ADD ./dist/ /usr/share/nginx/html/dist/
COPY nginx/prod.conf /etc/nginx/nginx.conf

EXPOSE 80

STOPSIGNAL SIGTERM

CMD ["nginx", "-g", "daemon off;"]

Разве это не очень чисто? Нам не нужно пересобирать образ локально. Мы также знаем, что эти бесполезные вещи не будут существовать в текущем собранном образе, потому что мы больше ничего не делаем, только дваcopyДействие, потом начало, готово.

Автоматически строить

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

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

Здесь я основываюсьgit hooksвыполнить автоматическую реализацию сборки,git hooksЕсть такой крючокpre-push, что является некоторым поведением перед отправкой кода.

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

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

// .huskyrc.js
module.exports = {
  hooks: {
    'pre-push': `\
      npm run build && \
      docker build -t images:tag PATH(当前项目目录) && \
      // 这里发送到平台上，用于镜像的发布
    `,
  },
}

Экологическое отличие

Если обычно мы работаем, отправка кода осуществляется в соответствии сgit flowКстати, тогда эта проблема решается очень хорошо, получаем текущую ветку:

// 获取当前分支名称
const branch = execSync('git rev-parse --abbrev-ref HEAD')
  .toString()
  .replace(/\s+/, '')

Различать то, что мы хотим выполнить, путем ветвленияbuildЗаказ,imagesимя зеркала,dockerfileдокумент:

var branchAuthority = {
  'dev': {
    docker: 'Dockerfile.test',
    image: 'local-test',
    build: 'npm run build:test',
  },
}

Исправлять.huskyrc.js:

module.exports = {
  hooks: {
    'pre-push': `\
      ${build} && \
      docker build -f ${docker} -t ${image:tag} ${path}
    `,
  },
}

Общий процесс, вероятно, таков, а остальное — оптимизация некоторых деталей, например, если планированиеbranchAuthorityСтруктура, построение образа, необходимость удаления локального образа после завершения выпуска и другие оптимизированные действия.

Суммировать

Сравнение эффектов

До оптимизации: Размер изображения составляет 1,65 ГБ, а время создания и выпуска составляет около 600 секунд;

Оптимизировано: Размер образа составляет 350 МБ, а время сборки и выпуска — около 120 с.

оптимизированные шаги

  • Установитьgit hooksа такжеdockerfile
  • Делайте различия в среде, образе, докере
  • После завершения локального построения запустите контейнер локально и сначала проверьте, нет ли проблем с процессом.Если проблем нет, он встраивается вpre-pushсередина
  • Наконец, вы можете бежать

конец

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

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

Категории