Я развертываю свое приложение NuxtJS с помощью сценария развертывания, который я добавил ниже. Я использую некоторые инструкции из этого руководства: https://www.digitalocean.com/community/tutorials/how-to-automate-deployment-using-circleci-and-github-on-ubuntu-18-04
Если я получаю доступ к своей капле с помощью SSH и запускаю сценарий deploy.sh вручную, кажется, что все работает нормально. Но как только CircleCI запускает экземпляр докера (см. Config.yml ниже), ему нужно как минимум 5 минут для запуска скрипта, если мне повезет. И при этом процессор моей капли резко набирает обороты, и требуется много терпения, пытаясь повторно подключиться к моей капле с помощью SSH с моего локального компьютера.
Довольно странно, что это происходит только при запуске скрипта через CircleCI. На всякий случай попробовал раскрутить средний докер вместо маленького, но безуспешно. В большинстве случаев развертывание завершается через 10 минут, поэтому в большинстве случаев я получаю неудачное развертывание.
Если CircleCI выходит из строя, CPU моего дроплета остается более 100%, а node_modules/.bin/nuxt build продолжает работать. Перезагрузка капли - самое простое решение (иногда необходимо, если повторное подключение с использованием SSH просто невозможно или терминал, который уже подключен, больше не отвечает). После перезагрузки первое развертывание CircleCi завершается успешно, а остальные снова терпят неудачу.
Я посмотрел на htop, и кажется, что kswapd0 занимает более 40% ЦП, snapd - более 30, а остальные - для узла и т. д.
deploy.sh
#!/bin/bash
#move to project folder
cd /var/www/mywebsite.nl
#pull from the branch
git pull origin main
# build nuxt project and run pm2
npm install
npm run build
pm2 start
circleci config.yml
version: 2.1
jobs:
deploy:
docker:
- image: buildpack-deps:trusty
resource_class: small # we use a small docker instance to use as little credits as possible
steps:
- add_ssh_keys:
fingerprints:
- "xx:xx:xx:xx:xx:xx:xx:xx"
- run:
name: Deploy Over SSH
command: |
ssh -oStrictHostKeyChecking=no -v $SSH_USER@$SSH_HOST "./deploy.sh"
workflows:
build-and-deploy:
jobs:
- deploy:
filters:
branches:
only:
- main # only deploy on the main branch
nuxt.config.js
import webpack from 'webpack'
export default {
// Disable server-side rendering: https://go.nuxtjs.dev/ssr-mode
ssr: false,
// Target: https://go.nuxtjs.dev/config-target
target: 'server',
// Global page headers: https://go.nuxtjs.dev/config-head
head: {
title: 'myapp',
htmlAttrs: {
lang: 'en'
},
meta: [
{ charset: 'utf-8' },
{ name: 'viewport', content: 'width=device-width, initial-scale=1' },
{ hid: 'description', name: 'description', content: '' }
],
link: [
{ rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' }
]
},
// Global CSS: https://go.nuxtjs.dev/config-css
css: [
'@/assets/sass/main'
],
// Plugins to run before rendering page: https://go.nuxtjs.dev/config-plugins
plugins: [{
src: '~plugins/vue-scrollmagic.js',
ssr: false
}],
// Auto import components: https://go.nuxtjs.dev/config-components
components: true,
// Modules for dev and build (recommended): https://go.nuxtjs.dev/config-modules
buildModules: [
['nuxt-fontawesome', {
component: 'fa', //customize component name
imports: [{
set: '@fortawesome/free-brands-svg-icons',
icons: ['fab']
},
]
}]
],
build: {
loaders: {
vue: {
prettify: false
}
}
},
// Modules: https://go.nuxtjs.dev/config-modules
modules: [
'@nuxtjs/sitemap'
],
sitemap: {
hostname: 'https://mydomain.nl'
}
}
Есть предположения?
Моя капля: 1 ГБ памяти / 25 ГБ диск / AMS3 - Ubuntu 20.04 (LTS) x64





Сохранение некоторой памяти для других процессов, установка параметра --max-old-space-size в процессе сборки в package.json, похоже, решает эту проблему. Мое приложение было развернуто менее чем за минуту.
"build": "node --max-old-space-size=600 node_modules/nuxt/bin/nuxt.js build"
Иногда этого недостаточно, когда моя машина в какой-то момент фактически использует больше памяти, поэтому я думаю, что самый безопасный вариант - использовать 2 ГБ.
С другой стороны, это происходит только во время сборки приложения, поэтому я думаю, что могу сообщить о проблеме на GitHub на всякий случай.