Автоматическое развёртывание Vue.js-приложений

Рассказывает Чейз Руссин — разработчик

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

В этой статье я предположу, что вы уже создали приложение Vue.js, и теперь готовы к его установке с помощью сервиса непрерывного развёртывания в GitLab.

Прежде чем начать, давайте зарегистрируем аккаунт AWS и создадим новую корзину S3. Все новые аккаунты AWS подпадают под уровень бесплатного использования, что позволит нам бесплатно развёртываться на S3 (в течение первого года и с ограничениями некоторых запросов).

S3

После регистрации перейдите в консоль S3 и нажмите «Create Bucket» (Создать корзину).

Окно создания корзины

Перед вами откроется такое модальное окно. Введите имя корзины (помните, что для AWS оно должно быть уникальным). На вкладке «Set Permissions» («установить разрешения») убедитесь, что вы сняли флажки «Block new public bucket policies» («Блокировать новые общедоступные политики корзины») и «Block public and cross-account access if bucket has public policies» («Блокировать публичный доступ и доступ между аккаунтами, если корзина имеет общедоступные политики»):

Когда создадите корзину, щёлкните по ней и перейдите на вторую вкладку с именем «Properties» («Свойства»). Вы увидите форму с именем «Static website hosting» («Статический хостинг»). Кликните по нему, включите «use this bucket to host a website» («использовать этот сегмент для размещения веб-сайта») и введите «index.html» в поле «index document»:

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

Наконец, откройте в вашей корзине S3 разрешение на чтение (чтобы пользователи смогли увидеть ваш потрясающий веб-сайт). Перейдите на третью вкладку с надписью «Permissions» («Разрешения») и нажмите «Bucket Policy» («Политика корзины»). Вам нужно будет добавить следующую политику в редакторе:

			{
   "Version": "2012-10-17",
   "Statement": [
       {
           "Effect": "Allow",
           "Principal": "*",
           "Action": "s3:GetObject",
           "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
       }
   ]
}
		

Не забудьте заменить YOUR_BUCKET_NAME именем корзины, которое вы использовали при создании.

Вернитесь на вкладку «Public Access Settings» («Настройки общего доступа») и включите блокировку новых политик корзины:

Теперь, если мы перейдём по URL, который Amazon назначил этой корзине, должно появиться… сообщение 404! Это потому что мы ещё не запустили проект из GitLab!

Последнее, что мы должны сделать на панели инструментов AWS, — это создать пользователя IAM, чтобы мы могли безопасно разрешить GitLab доступ и загрузку данных в нашу корзину. Это позволит отозвать доступ, если нам когда-нибудь это понадобится.

Пользователь IAM

Перейдите к консоли управления IAM и нажмите синюю кнопку «Add user» («Добавить пользователя») вверху. Введите имя пользователя, например gitlabci, и выберите «Programmatic access» («Программный доступ»).

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

Когда вы нажмёте «create user» («создать пользователя»), вы попадёте на страницу успешного завершения операции. Эта страница будет содержать важную информацию: ключ доступа и секретный ключ ( после выхода с этой страницы у вас больше не будет доступа к секретному ключу). Вы можете либо записать их, либо скачать файл .csv, а затем удалить его позже. Что бы вы ни делали, убедитесь, что никто не получит доступ к этим ключам.

Загрузите CSV-файл, либо нажмите «Показать секретный ключ» и скопируйте куда-нибудь

Мы почти закончили. Теперь нам просто нужно настроить GitLab для запуска корзины S3.

GitLab

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

Перейдите в GitLab, зарегистрируйте аккаунт и создайте новый проект. GitLab аналогичен GitHub в том смысле, что вам нужно будет добавить его удалённый источник в ваш локальный проект. Как только проект настроен, переименуйте/добавьте его как удалённый в свой локальный .git:

			git remote rename origin old-origin
git remote add origin https://gitlab.com/croossin/vues3example.git
git push -u origin --all
		

Теперь изменим ключевой файл, необходимый для установки GitLab CI/CD:

			stages:
  - build
  - deploy

build prod:
  image: node:10.15.0-stretch
  stage: build
  only:
    - tags
  script:
    # Установка vuecli
    - npm install -g @vue/cli@latest
    # Установка зависимостей
    - npm install
    # Сборка приложения
    - npm run build
  artifacts:
    paths:
      # Создание директории
      - dist/
    expire_in: 1 hour

deploy prod:
  image: python:latest
  stage: deploy
  only:
    - tags
  script:
    - pip install awscli
    - aws s3 sync ./dist s3://YOUR_BUCKET_NAME

build stage:
  image: node:10.15.0-stretch
  stage: build
  only:
    - master
  script:
    # Установка vuecli
    - npm install -g @vue/cli@latest
    # Установка зависимостей
    - npm install
    # Сборка приложения
    - npm run build-dev
  artifacts:
    paths:
      # Создание директории
      - dist/
    expire_in: 1 hour

deploy stage:
  image: python:latest
  stage: deploy
  only:
    - master
  script:
    - pip install awscli
    - aws s3 sync ./dist s3://YOUR_DEV_BUCKET_NAME
		

Перейдите в корневой каталог вашего приложения, добавьте файл .gitlab-ci.yml и скопируйте в него фрагмент выше; после первого запуска GitLab автоматически распознает код и начнёт процесс развёртывания.

Что именно делает этот файл?

			stages:
  - build
  - deploy
		

Он сообщает GitLab, какие «шаги» нужно выполнить во время процесса CI/CD. Вы можете легко отказаться от добавления дополнительных шагов, например, test и прочих. Давайте рассмотрим первый этап .

Сборка

			build prod: 
  image: node:10.15.0-stretch 
  stage: build 
  only:   
     - tags 
  script:   
     # Установка vuecli   
     - npm install -g @vue/cli@latest   
     # Установка зависимостей
     - npm install   
     # Сборка приложения
     - npm run build 
  artifacts:   
     paths:     
        # Создание директории   
        - dist/   
     expire_in: 1 hour
		

• image: Так как производится сборка приложения, нужно установить в image версию Node (предпочтительно последнюю).
• stage: Этот тег должен совпадать с одним из этапов (в данном случае build или deploy), которые мы описали в самом верху файла. Это позволяет GitLab понять, как эти этапы связаны.
• only: Этот тег очень важен, если вы хотите, чтобы GitLab запускал выполнение скриптов, основанных на определённой ветке или теге. Лично мне нравится настраивать stage и production среды. Когда я объединяю изменения в master, запускаются скрипты сборки, а когда я вызываю нужный тег, запускаются его скрипты.
• script: Это последовательность команд, которые запускаются на данном шаге. Для этого конкретного случая необходимо установить последнюю версию Vue Cli, загрузить все зависимости, а затем запустить скрипт сборки из package.json, который выглядит примерно так: vue-cli-service build.
• artifacts: Вот что заставило меня споткнуться вначале. Поскольку у нас есть два этапа (сборка и развёртывание), и они оба находятся в двух разных образах, нам нужно, чтобы второй этап (развёртывание) имел доступ к папке сборки dist/. С помощью artifacts мы можем установить путь к «хранилищу», чтобы другие этапы могли ссылаться на него. Таким образом, я настроил свой путь к папке dist/ и установил срок действия на 1 час.

Теперь последний этап в этом конвейере.

Развёртывание

			deploy prod: 
  image: python:latest 
  stage: deploy 
  only:   
     - tags 
  script:   
     - pip install awscli   
     - aws s3 sync ./dist s3://YOUR_BUCKET_NAME
		

Язык Python поддерживается CLI для AWS, поэтому мы установили тег image на python:latest. Когда скрипт запустится, он установит последний CLI AWS и синхронизирует папку dist с корзиной, которую мы создали в начале. Убедитесь, что YOUR_BUCKET_NAME совпадает с именем корзины, которую мы создали в консоли S3.

Прим. Если вы хотите использовать и stage, и production среды, вам нужно будет создать вторую корзину в S3 (с той же конфигурацией, что и первая) и использовать её в качестве stage корзины.

Последний шаг

Благодаря пользователю IAM, созданному ранее, AWS должен разрешить GitLab доступ к нашей корзине. Поскольку это крайне плохая практика разглашать/записывать ваши ключи, мы добавим их в переменные среды GitLab. Перейдите в раздел CI/CD на вкладке «Settings» («Настройки») и разверните «Environment Variables» («Переменные среды»).

Добавьте две переменные: AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY. Заполните значения соответствующими ключами, которые вы загрузили/скопировали при создании пользователя в консоли управления IAM.

Проверить успешное завершение развёртывания вы можете, вставив какой-нибудь код в master и увидев, как GitLab автоматически запускает процесс CI/CD. Вы можете наблюдать за выполнением этапов и видеть все запущенные вами конвейеры развёртывания:

Взгляните на документацию по GitLab CI/CD, чтобы узнать, как вы можете расширить свои проекты для выполнения всего, что вам нужно.

Резюмируя

После выполнения всех этих шагов у вас уже должен быть:

• Создан аккаунт AWS,
• Создана корзина S3 и установлены разрешения на публичный доступ,
• Создан пользователь IAM для использования GitLab,
• Создан аккаунт и проект GitLab,
• Добавлен файл .gitlab-ci.yml и заполнены этапы CI/CD,
• Добавлены учётные данные IAM в переменные среды.

Расслабьтесь, улыбнитесь и наблюдайте, как ваш код автоматически разворачивается на S3 через GitLab CI/CD.