Front-end Advanced Advancement: История разработки Front-end Deployment

опрос внешний фреймворк
  1. Front-end advanced advanced: как сжимается код javascript
  2. Advanced front-end advanced: как лучше оптимизировать ресурсы упаковки
  3. Advanced Front-end Advanced: рекомендации и меры предосторожности для стратегии управления кэшем веб-сайта
  4. Frontend Advanced Advanced: ускорьте работу npm i на 50 %
  5. Расширенный интерфейс: используйте докер для эффективного развертывания интерфейсных приложений.
  6. Front-end advanced advanced: развертывание интерфейсной многофункциональной среды филиала в рамках CICD
  7. Front-end Advanced Advancement: История разработки Front-end Deployment

Еще статьи:Передовая инженерная серия

Я создал новый репозиторий на githubВопрос дня, интервью вопрос каждый день, добро пожаловать в общение.

Когда в интерфейсе говорится о резком сокращении и сжигании, за ним должна следовать тема фронтенд-инжиниринга. вместе сreact/vue/angular,es6+,webpack,babel,typescriptтак же какnodeРазвитие фронтенда постепенно вытеснило прошлоеscriptСвинецcdnПуть развития положил начало большой инженерной волне. Благодаря развитию инженерии и хорошей экологии сообщества открытого исходного кода, удобство использования и эффективность фронтенд-приложений значительно улучшились.

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

Это только часть, и более важная причина заключается в том,devopsрост.

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

  1. Кэш, http во фронтенд приложенияхresponse headerКем? Благодаря развитию инженерии файлы со значениями хеш-функции после упаковки могут постоянно кэшироваться
  2. перекрестный домен,/apiКто будет настраивать конфигурацию прокси? Вы можете открыть небольшую службу во внешнем интерфейсе среды разработки и включитьwebpack-dev-serverНастройте междоменное взаимодействие, как насчет производственной среды

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

Время пришлоReactТолько что разработан в этом году, это время было использованоReactразрабатывать приложения, использоватьwebpackупаковать. Но фронтенд-развертывание по-прежнему носит строгий характер.

Эта статья требует от вас определенных знаний о Docker, DevOps и интерфейсной инженерии. Если нет, то эта серия статей иРуководство по эксплуатации и обслуживанию персонального сервераРаздел Docker в поможет вам.

слешь и гореть

трамплин

Рабочий сервер

сценарий развертывания

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

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

В это время внешние статические файлы создаютсяnginxхостинг,nginxФайл конфигурации выглядит так

server {
  listen 80;
  server_name shanyue.tech;

  location / {
    # 避免非root路径404
    try_files $uri $uri/ /index.html;
  }

  # 解决跨域
  location /api {
    proxy_pass http://api.shanyue.tech;
  }

  # 为带 hash 值的文件配置永久缓存
  location ~* \.(?:css|js)$ {
      try_files $uri =404;
      expires 1y;
      add_header Cache-Control "public";
  }

  location ~ ^.+\..+$ {
      try_files $uri =404;
  }
}

Но... часто я не могу бежать

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

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

Но всегда

Лу Синь сказал: «Это всегда было так, верно?»

В настоящее время как междоменная конфигурация, так и конфигурация кэша управляются эксплуатацией и обслуживанием, а эксплуатация и обслуживание не понимают внешний интерфейс. Но метод настройки предоставляется фронтендом, а фронтенд не знаком с nginx

Создайте образ с помощью докера

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

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

интерфейс написанdockerfileпримерно так

FROM node:alpine

# 代表生产环境
ENV PROJECT_ENV production
# 许多 package 会根据此环境变量，做出不同的行为
# 另外，在 webpack 中打包也会根据此环境变量做出优化，但是 create-react-app 在打包时会写死该环境变量
ENV NODE_ENV production
WORKDIR /code
ADD . /code
RUN npm install && npm run build && npm install -g http-server
EXPOSE 80

CMD http-server ./public -p 80

иметь толькоdockerfileОн не может работать, и передняя часть также начала поддерживатьdocker-compose.yaml, и передать его в эксплуатацию и техническое обслуживание для выполнения командыdocker-compose up -dЗапустите интерфейсное приложение. Первая запись в интерфейсеdockerfileа такжеdocker-compose.yaml, играя все более важную роль в процессе развертывания. Думая о дальнейшем расширении моего базового диска, передняя часть не может не улыбаться счастливо

version: "3"
services:
  shici:
    build: .
    expose:
      - 80

оперативныйnginxФайл конфигурации выглядит так

server {
  listen 80;
  server_name shanyue.tech;

  location / {
    proxy_pass http://static.shanyue.tech;
  }

  location /api {
    proxy_pass http://api.shanyue.tech;
  }
}

Эксплуатация и обслуживаниеnginxКроме того, выполните команду:docker-compose up -d

В это время подумайте над первыми двумя вопросами в статье

  1. Кэш, в связи с переходом от статических файлов к отдаче, кеш начинает контролироваться фронтендом (ноhttp-serverне подходит для этого)
  2. Междоменный, междоменный по-прежнему контролируется эксплуатацией и обслуживаниемnginxСредняя конфигурация

Внешний интерфейс может делать часть того, что он должен делать, и это радует.

Конечно, передняя часть дляdockerfileУлучшение также является процессом постепенной эволюции, так в чем проблема с зеркалированием в настоящее время?

  1. Слишком большой размер образа сборки
  2. Создание образа занимает слишком много времени

Используйте многоэтапные сборки для оптимизации изображений

На самом деле, в середине было много взлетов и падений.Подробности процесса можно найти в другой моей статье:Как развернуть интерфейсные приложения с помощью Docker.

Основная оптимизация также заключается в двух аспектах, упомянутых выше.

  1. Объем образа сборки изменен с 1G+ на 10M+
  2. Время сборки образа изменено с 5мин+ на 1мин (в зависимости от сложности проекта, большая часть времени уходит на сборку и загрузку статических ресурсов)
FROM node:alpine as builder

ENV PROJECT_ENV production
ENV NODE_ENV production

WORKDIR /code

ADD package.json /code
RUN npm install --production

ADD . /code

# npm run uploadCdn 是把静态资源上传至 oss 上的脚本文件，将来会使用 cdn 对 oss 加速
RUN npm run build && npm run uploadCdn

# 选择更小体积的基础镜像
FROM nginx:alpine
COPY --from=builder code/public/index.html code/public/favicon.ico /usr/share/nginx/html/
COPY --from=builder code/public/static /usr/share/nginx/html/static

как это делается

  1. ПервыйADD package.json /code, Опять такиnpm install --productionПозжеAddВсе файлы. Воспользуйтесь преимуществами кэширования изображений, чтобы сократить время сборки
  2. Многоступенчатая сборка, значительно уменьшающая размер изображения

Кроме того, могут быть некоторые небольшие оптимизации, такие как

  • npm cacheбазовое изображение илиnpmЧастные репозитории, уменьшитьnpm installвремя, сокращая время сборки
  • npm install --productionПакуйте только необходимые пакеты

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

В это время подумайте над первыми двумя вопросами в статье

  1. Кэш, кеш контролируется внешним интерфейсом, кеш установлен на oss, и будет использовать cdn для ускорения oss. На данный момент кеш управляется внешним скриптом, написанным
  2. Междоменный, междоменный по-прежнему контролируется эксплуатацией и обслуживаниемnginxСредняя конфигурация

CI/CD и gitlab

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

  1. вытащить код
  2. docker-compose up -d
  3. перезапустить nginx

O&M почувствовал, что так больше продолжаться не может, поэтому представилCI: с существующим репозиторием кодаgitlabдополнительныйgitlab ci

  • CI,Continuous IntegrationНепрерывная интеграция
  • CD,Continuous Delivery, постоянная доставка

важно неCI/CDЧто это такое, важно то, что теперь эксплуатация и обслуживание не должны следить за бизнесом в режиме онлайн, и нет необходимости постоянно пялиться на развертывание переднего плана. все этоCI/CDДело в том, что он используется для автоматического развертывания. Три вещи, упомянутые выше, передаютсяCI/CD

.gitlab-ci.ymlдаgitlabФайл конфигурации CI, который выглядит так

deploy:
  stage: deploy
  only:
    - master
  script:
    - docker-compose up --build -d
  tags:
    - shell

CI/CDНе только освобождает от развертывания бизнес-проектов, но и значительно повышает качество бизнес-кода перед доставкой, его можно использовать дляlint,test,packageПроверки безопасности и даже многофункциональное развертывание в нескольких средах, я напишу об этой части в своих будущих статьях.

Один из моих серверных проектовshfshanyue/shiciНа моем сервере раньше былоdocker/docker-compose/gitlab-ciЕсли вам интересно, вы можете взглянуть на его файл конфигурации.

Если у вас есть личный сервер, также рекомендуется сделать интерфейсное приложение и поддержку интересующих вас серверных интерфейсных сервисов, а также поддержкуCI/CDРазверните его на своем собственном сервере

и если вы хотите совместитьgithubДелатьCI/CD, тогда можно попробоватьgithub + github action

Кроме того, вы можете попробоватьdrone.ci, как развернуть можете обратиться к моей предыдущей статье:Внедрение и развертывание решения для непрерывной интеграции Drone на github

Развертывание с помощью kubernetes

По мере того, как бизнес становится все больше и больше, появляется все больше и больше зеркал.docker-composeбольше не могу с этим справляться,kubernetesВыходите вовремя. В это время сервер также изменился с одного на несколько, и у нескольких серверов будут распределенные проблемы.

Появление новой технологии усложняет решение предыдущих проблем.

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

Итак, какие новые проблемы возникают сейчас?

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

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

Давайте посмотрим на предыдущий процесс:

  1. Интерфейсная конфигурацияdockerfileа такжеdocker-compose
  2. рабочий серверCI runnerКод вытягивания (можно рассматривать как предыдущую операцию и техническое обслуживание),docker-compose up -dЗапустите службу. затем перезапуститеnginx, в качестве обратного прокси для предоставления внешних услуг

Возникла проблема с предыдущим процессом:Сервер для сборки образов, сервер для предоставления контейнерных услуг и сервер для непрерывной интеграции!, поэтому вам нужен частный зеркальный репозиторий, к которому можно получить доступk8sКластерный сервер непрерывной интеграции

Объединить после улучшения процессаk8sПроцесс выглядит следующим образом

  1. Интерфейсная конфигурацияdockerfile, создайте образ и поместите его в репозиторий образов
  2. Эксплуатация и обслуживание настроены для интерфейсных приложенийk8sфайл конфигурации ресурсов,kubectl apply -fповторно загрузит образ и развернет ресурсы

Эксплуатация и обслуживание спрашивайте у фронтенда, нужно ли расширять свой основной диск, напишите про фронтендk8sФайл конфигурации ресурсов и список нескольких статей.

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

В настоящее время,gitlab-ci.yamlВыглядит так, права доступа к конфигурационному файлу управляются одним оператором и специалистом по обслуживанию.

deploy:
  stage: deploy
  only:
    - master
  script:
    - docker build -t harbor.shanyue.tech/fe/shanyue
    - docker push harbor.shanyue.tech/fe/shanyue
    - kubectl apply -f https://k8s-config.default.svc.cluster.local/shanyue.yaml
  tags:
    - shell

В это время подумайте над первыми двумя вопросами в статье

  1. Кэш, кеш контролируется внешним интерфейсом
  2. Междоменный, междоменный по-прежнему контролируется эксплуатацией и обслуживанием в бэкэнде.k8sУправление файлом конфигурации ресурсовIngress

Развертывание со штурвалом

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

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

Так что естьhelm, если объяснить одним предложением, это шаблонная функция сk8sФайл конфигурации ресурсов. В качестве внешнего интерфейса вам нужно только заполнить параметры. Для более подробной информации, пожалуйста, обратитесь к моим предыдущим статьямРазвертывание ресурсов k8s с помощью helm

если мы используемbitnami/nginxтак какhelm chart, конфигурационный файл, который может записать интерфейс, выглядит так

image:
  registry: harbor.shanyue.tech
  repository: fe/shanyue
  tag: 8a9ac0

ingress:
  enabled: true
  hosts:
  - name: shanyue.tech
    path: /

  tls:
  - hosts:
      - shanyue.tech
    secretName: shanyue-tls

    # livenessProbe:
    #   httpGet:
    #     path: /
    #     port: http
    #   initialDelaySeconds: 30
    #   timeoutSeconds: 5
    #   failureThreshold: 6
    #
    # readinessProbe:
    #   httpGet:
    #     path: /
    #     port: http
    #   initialDelaySeconds: 5
    #   timeoutSeconds: 3
    #   periodSeconds: 5

В это время подумайте над первыми двумя вопросами в статье

  1. Кэш, кеш контролируется внешним интерфейсом
  2. Междоменный, междоменный, управляемый бэкендом, настроенный в конфигурационном файле бэкенда Chartvalues.yamlсередина

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

Вещи, которые должен сделать передний конец:

  1. Пишите интерфейсные сборкиdockerfile, это просто разовая работа, и со ссылкой
  2. использоватьhelmУкажите параметры при развертывании

Что с эксплуатацией и обслуживанием?

  1. Предоставляет тот, который используется всеми интерфейсными проектами.helm chart, даже не нужно его предоставлять, если эксплуатация и обслуживание ленивы, используйте егоbitnami/nginxБар. тоже разовая работа
  2. предоставить на основеhelmИнструмент, запрещающий слишком много разрешений для бизнеса или даже не требующий их предоставления, если эксплуатация и обслуживание относительно ленивы, используйте его напрямуюhelm

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

Унифицированная платформа внешнего развертывания

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

  1. CI/CD: автоматическое развертывание при отправке кода в определенную ветку репозитория.
  2. http headers: вы можете настроить ресурсhttp header, чтобы это можно было сделатьоптимизация кешаЖдать
  3. http redirect/rewrite: еслиnginx, так что вы можете настроить/api, для решения междоменных проблем
  4. hostname: Вы можете установить доменное имя
  5. CDN: отправить ваши статические ресурсы в CDN
  6. https: Подготовьте сертификат для вас
  7. Prerender: комбинированныйSPA, сделать предварительный рендеринг

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

build:
  command: npm run build
  dist: /dist

hosts:
- name: shanyue.tech
  path: /

headers:
- location: /*
  values:
  - cache-control: max-age=7200
- location: assets/*
  values:
  - cache-control: max-age=31536000

redirects:
- from : /api
  to: https://api.shanyue.tech
  status: 200

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

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

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

Рендеринг на стороне сервера и внутреннее развертывание

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

Бэкенд-развертывания более сложны, например,

  1. Для настройки служб серверной части необходим доступ к конфиденциальным данным, но он не может помещать конфиденциальные данные в репозиторий кода. ты сможешьenvironment variables,consulилиk8s configmapсреднее обслуживание
  2. Для восходящих и нисходящих служб вам необходимо полагаться на базы данных, восходящие службы
  3. Контроль доступа, ограниченный IP, черный и белый список
  4. RateLimit
  5. так далее

Я поделюсь, как развернуть бэкенд в k8s, в следующей статье.

резюме

вместе сdevopsразработка, фронтенд-развертывание становится проще и управляемее, всем рекомендуется немного научитьсяdevopsс вещами.

Дорога длинная и длинная, и дорога приближается.

общаться со мной

Отсканируйте код, чтобы добавить моего робота WeChat, это будетавтоматический(Программа автоматического втягивания находится в стадии разработки) Вовлеките вас в группу продвинутого продвинутого обучения переднего плана

Порекомендуйте публичный аккаунт о найме в Дачане [Интернет-рекрутинг в Дачане], автор будет продолжать продвигать вакансии и требования каждой крупной фабрики в общедоступном аккаунте, а также напрямую общаться с интервьюерами и менеджерами по найму в Дачане.Если вы заинтересованы, вы можете Общайтесь напрямую с ответственным лицом.

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

Я создал новый репозиторий на githubВопрос дня, интервью вопрос каждый день, добро пожаловать в общение.

更多大厂招聘，面试面经，技能要求，请关注公众号【互联网大厂招聘】

Категории