2016-11-09 7 views
8

У меня есть экземпляр AWS Ubuntu с настройкой GitLab CE. Теперь я хочу настроить GitLab CI для развертывания моего приложения NodeJS после каждой фиксации. У меня нет правильного пошагового решения для этого.Установка GitLab CI для развертывания NodeJS в экземпляре AWS Ubuntu

Моего NodeJS приложения работает в /var/www/mean/my-app на http://myapp.mydomain.com и хостинг обрабатывается Apache Proxy,

<VirtualHost *:80> 
    ServerAdmin [email protected] 
    ServerName gitlab.mydomain.com 
    ServerAlias www.gitlab.mydomain.com 

    ServerSignature Off 

    ProxyPreserveHost On 

    AllowEncodedSlashes NoDecode 

    <Location /> 
     Require all granted 
     ProxyPassReverse http://localhost:8080 
     ProxyPassReverse http://gitlab.mydomain.com/ 
    </Location> 

    RewriteEngine on 

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f [OR] 
    RewriteCond %{REQUEST_URI} ^/uploads/.* 
    RewriteRule .* http://127.0.0.1:8080%{REQUEST_URI} [P,QSA,NE] 

    DocumentRoot /home/git/gitlab/public 

    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded 
    ErrorLog /var/log/apache2/gitlab_error.log 
    CustomLog /var/log/apache2/gitlab_forwarded.log common_forwarded 
    CustomLog /var/log/apache2/gitlab_access.log combined env=!dontlog 
    CustomLog /var/log/apache2/gitlab.log combined 
</VirtualHost> 

И приложение бутстрапируемое используя навсегда модуль

forever start app.js 

gitlab проверка конфигурации sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production дает,

Checking GitLab Shell ... 

GitLab Shell version >= 4.0.0 ? ... OK (4.0.0) 
Repo base directory exists? 
default... yes 
Repo storage directories are symlinks? 
default... no 
Repo paths owned by git:git? 
default... yes 
Repo paths access is drwxrws---? 
default... yes 
hooks directories in repos are links: ... 
dev/my-app ... ok 
Running /home/git/gitlab-shell/bin/check 
Check GitLab API access: OK 
Access to /home/git/.ssh/authorized_keys: OK 
Send ping to redis server: OK 
gitlab-shell self-check successful 

Checking GitLab Shell ... Finished 

Checking Sidekiq ... 

Running? ... yes 
Number of Sidekiq processes ... 1 

Checking Sidekiq ... Finished 

Checking Reply by email ... 

Reply by email is disabled in config/gitlab.yml 

Checking Reply by email ... Finished 

Checking LDAP ... 

LDAP is disabled in config/gitlab.yml 

Checking LDAP ... Finished 

Checking GitLab ... 

Git configured with autocrlf=input? ... yes 
Database config exists? ... yes 
All migrations up? ... yes 
Database contains orphaned GroupMembers? ... no 
GitLab config exists? ... yes 
GitLab config outdated? ... no 
Log directory writable? ... yes 
Tmp directory writable? ... yes 
Uploads directory setup correctly? ... yes 
Init script exists? ... yes 
Init script up-to-date? ... yes 
projects have namespace: ... 
dev/my-app ... yes 
Redis version >= 2.8.0? ... yes 
Ruby version >= 2.1.0 ? ... yes (2.3.1) 
Your git bin path is "/usr/bin/git" 
Git version >= 2.7.3 ? ... yes (2.7.4) 
Active users: 1 

Checking GitLab ... Finished 

Я использовал для входа в систему к экземпляру с помощью SSH из моей системы,

ssh -i API-Key.pem [email protected] 

создал ключ, используя команду

ssh-keygen -t rsa 

Runner конфигурации на /etc/gitlab-runner/config.toml

concurrent = 1 
check_interval = 0 

[[runners]] 
    name = "Production Runner" 
    url = "http://gitlab.mydomain.com/ci" 
    token = "xxxxxxxxxxxxxxxxxxxxxxxxxxx" 
    executor = "ssh" 
    [runners.ssh] 
    user = "ubuntu" 
    host = "ip-XXX-XX-XX-XXX" 
    identity_file = "/home/ubuntu/.ssh/id_rsa" 
    [runners.cache] 

кодекса .gitlab-ci.yml

test_async: 
script:  
    - npm install 

Из-за мою плохую конфигурацию, бегун дает ошибку,

Running with gitlab-ci-multi-runner 1.7.1 (f896af7) 
Using SSH executor... 
ERROR: Preparation failed: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain 
Will be retried in 3s ... 

Моим неурядиц является:

Что должен быть содержанием .gitlab-ci.yml файла для развертывания допущенного кода в место приложения?

А как настроить бегун для этого? Если мне нужно использовать бегун ssh, какими должны быть конфигурации там?

Update:

После предоставления .pem файла как identity_file, получает следующее сообщение об ошибке

Running with gitlab-ci-multi-runner 1.7.1 (f896af7) 
Using SSH executor... 
Running on ip-xxx-xx-xx-xxx via ip-xxx-xx-xx-xxx... 
Cloning repository... 
Cloning into 'builds/a92f1b91/0/dev/my-app'... 
fatal: unable to access 'http://gitlab-ci-token:[email protected]/dev/my-app.git/': The requested URL returned error: 500 
ERROR: Build failed: Process exited with: 1. Reason was: () 

Теперь есть проблема, мерзавец клон с HTTP не работает, но SSH клонирования работы.

Примечание: Оба gitlab и строить среды такие же хост (такой же AWS экземпляр)

Bug сообщили в GitLab, а также (HTTP клон вопрос).

+0

В настоящее время мы имеем Gitlab и Gitlab CI и работает только штрафом в АМС, его довольно стандартный. Тем не менее, хотя вы предоставили множество шагов по настройке Gitlab, вы не предоставили никакой информации о своих VPC, группе безопасности, подсети, NACL или каких-либо других сетевых настройках AWS. Подтвердили ли вы базовое подключение через порт 80 или 443? Похоже, у вас есть три системы в игре, Gitlab, Gitlab CI box и ваше приложение. Между каждой из них есть проблемы с подключением. –

+0

@NickSharp в моей группе безопасности VPC, у меня есть входящий и исходящий доступ из любого места. – devo

+0

Как я читал .. Каждый экземпляр GitLab CI имеет встроенный инструмент отладки под названием Lint. Вы можете найти ссылку под/ci/lint вашего экземпляра gitlab. Вы пробовали? – CristiC777

ответ

4

В вашем/etc/gitlab-runner/config.toml

concurrent = 1 
check_interval = 0 

[[runners]] 
    name = "Production Runner" 
    url = "http://gitlab.mydomain.com/ci" 
    token = "xxxxxxxxxxxxxxxxxxxxxxxxxxx" 
    executor = "ssh" 
    [runners.ssh] 
    user = "ubuntu" 
    host = "ip-XXX-XX-XX-XXX" 
    identity_file = "/home/ubuntu/.ssh/id_rsa" 
    [runners.cache] 

Вы определяете

  • хозяин
  • пользователя
  • и файл идентичности

хозяин должен быть ваш Сложение хоста IP (другими словами, где вы собираетесь выполнять ваша сборка)
пользователь должен быть вашим пользователем на Сборка хоста. Не на хосте gitlab.

Вы можете проверить, как ваш пароль менее SSH работает по

  1. Вход gitlab хозяин как корень
  2. SSH -i /home/ubuntu/.ssh/id_rsa убунту @ IP-XXX-XX-XX -XXX

Если это работает и не запрашивает у вас пароль - все хорошо.
Если это ломается - означает, что вы не настроили пароль менее auth правильно.

Самый простой способ установки пароля менее открытого ключа AUTH на основе заключается в использовании команды называется

ssh-copy-id 

Например, я хочу установить пароль менее SSH AUTH между моим gitlab и моей сборки хозяина.
My build host ip is 192.168.0.42, а имя хоста - build.home
У меня уже есть id_rsa и id_rsa.pub, сгенерированные под /home/ubuntu/.ssh на хосте gitlab.

Теперь давайте нажмем наш открытый ключ от хоста gitlab на наш узел сборки. В первый раз он попросит вас ввести пароль.

[[email protected] ~]# ssh-copy-id -i /home/ubuntu/.ssh/id_rsa.pub [email protected] 
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed 
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys 
[email protected]'s password: 

Number of key(s) added: 1 

Now try logging into the machine, with: "ssh '[email protected]'" 
and check to make sure that only the key(s) you wanted were added. 

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

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

[[email protected] ~]# ssh -i /home/ubuntu/.ssh/id_rsa [email protected] 
[[email protected] ~]$ hostname 
build.home 

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

Ресурсы:

Edit 1:

Вот мой конфиг.
Мой gitlab узел называется gitlab.home 192.168.0.41
И я другой VM называется sshbuild.home 192.168.0.43

Ниже, как я добавил SSH бегун

Шаг 1. Установите на мой gitlab.home yum install gitlab-ci-multi-runner и зарегистрировать удаленный sshbuild.home VM, как SSH бегуна

enter image description here

enter image description here

мне нужно, чтобы убедиться, что пароль менее аутентификации работает между моим gitlab.home и sshbuild.home, так

[[email protected] gitlab-runner]# ssh-copy-id 192.168.0.43 
The authenticity of host '192.168.0.43 (192.168.0.43)' can't be established. 
ECDSA key fingerprint is b4:6a:1b:72:d1:7d:1f:34:f7:bb:ef:ad:69:42:11:13. 
Are you sure you want to continue connecting (yes/no)? yes 
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed 
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys 
[email protected]'s password: 

Number of key(s) added: 1 

Now try logging into the machine, with: "ssh '192.168.0.43'" 
and check to make sure that only the key(s) you wanted were added. 

[[email protected] gitlab-runner]# ssh 192.168.0.43 
Last login: Fri Nov 18 17:05:06 2016 from 192.168.0.101 
[[email protected] ~]# exit 

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

enter image description here

и я совершить и вуаля - у нас есть преуспевающий тест, который был запущен на sshbuild.home хоста

enter image description here

Вот несколько ссылок, которые могут помочь с лучшего понимания этой темы

P.S: А вот мой /etc/gitlab-runner/config.toml файл

[[email protected] gitlab-runner]# cat /etc/gitlab-runner/config.toml 
concurrent = 1 
check_interval = 0 

[[runners]] 
    name = "sshbuild" 
    url = "http://gitlab.home/" 
    token = "2bc1825d8fbde09fd632637c60e9e7" 
    executor = "ssh" 
    [runners.ssh] 
    user = "root" 
    host = "192.168.0.43" 
    port = "22" 
    identity_file = "/root/.ssh/id_rsa" 
    [runners.cache] 

P.S: У меня есть аналогичные ошибки, как вам, если отключить HTTP для моей репо в разделе Настройки в веб-интерфейсе. Однако ошибка не 500, а 403.

enter image description here

Edit 2:

Теперь я расскажу .gitlab-ci.yml на основе простого HelloWorld проекта
В моей HelloWorld у меня есть файл называемый server.js, который при запуске с узла - просто создаст веб-сервер, работающий на сервере 3000, и ответит «Hello World» на запросы GET.

1 const http = require('http'); 
2 
3 const hostname = '0.0.0.0'; 
4 const port = 3000; 
5 
6 const server = http.createServer((req, res) => { 
7 res.statusCode = 200; 
8 res.setHeader('Content-Type', 'text/plain'); 
9 res.end('Hello World!\n'); 
10 }); 
11 
12 server.listen(port, hostname,() => { 
13 console.log(`Server running at http://${hostname}:${port}/`); 
14 }); 

Моя цель - уметь запустить тестовый пример против него.В этом случае я буду работать простой

curl localhost:3000 | grep "Hello World" 

Но мне нужно, чтобы поместить его в отдельный скрипт, который будет иметь статус выхода 0 в случае успеха и не ноль в случае неудачи

cat -n simpletest.sh 
    1 #!/bin/bash 
    2 
    3 cleanup() 
    4 { 
    5 count=`netstat -anp|grep ":3000"|grep LISTEN|awk '{print $NF}'|cut -d\/ -f1|wc -l` 
    6 if [ $count -ne 0 ] 
    7 then 
    8  pid=`netstat -anp|grep ":3000"|grep LISTEN|awk '{print $NF}'|cut -d\/ -f1`; 
    9  echo "Need to kill PID $pid"; 
    10  kill $pid 
    11 fi 
    12 } 
    13 
    14 echo "Running simple test" 
    15 curl localhost:3000|grep "Hello World" 
    16 if [ $? -eq 0 ] 
    17 then 
    18 echo "Test was successfull" 
    19 echo "Clean up node.js process" 
    20 cleanup 
    21 exit 0 
    22 else 
    23 echo "Test failed" 
    24 echo "Clean up node.js process" 
    25 cleanup 
    26 exit 1 
    27 fi 

Теперь давайте рассмотрим мой .gitlab -ci.yml

cat -n .gitlab-ci.yml 
    1 test: 
    2 
    3 before_script: 
    4 - echo "Before script" 
    5 - hostname 
    6 - /bin/bash cleanup.sh 
    7 
    8 script: 
    9 - echo "Main Script" 
    10 - node server.js & 
    11 - sleep 3 
    12 - /bin/bash simpletest.sh 

У меня есть одно задание, называемое тестом.
В before_script он запускает скрипт cleanup.sh, который просто убивает PID, прослушивая порт 3000 в случае такого обнаружения.

cat -n cleanup.sh 
    1 #!/bin/bash 
    2 count=`netstat -anp|grep ":3000"|grep LISTEN|awk '{print $NF}'|cut -d\/ -f1|wc -l` 
    3 if [ $count -ne 0 ] 
    4 then 
    5 pid=`netstat -anp|grep ":3000"|grep LISTEN|awk '{print $NF}'|cut -d\/ -f1`; 
    6 echo "Need to kill PID $pid"; 
    7 kill $pid 
    8 fi 
    9 exit 0 

И по сценарию: он работает узел с моим server.js, дает ему 3 секунды, чтобы начать, а затем запускает тест против него.
Этот тест также позаботится об убивании узла PID после завершения теста.

Так давайте фиксации и проверки состояния билда

enter image description here

А теперь давайте изменим наши server.js на выходе не «Hello World», но «HelloWorld», так что нет никакого пространства между ними. Я ожидаю, что мой тестовый пример потерпит неудачу, так как он ожидает буквально «Hello World». И он терпит неудачу.

enter image description here

Это наиболее упрощенным использование CI случае я мог придумать.
Теперь, если на основании состояния теста вы хотели бы разместить код в другую среду - вы должны начать использовать

  • этапы и
  • среды

Так что ваш. gitlab-ci.yml превратился бы во что-то подобное (настоящий рабочий пример)

cat -n .gitlab-ci.yml 
    1 stages: 
    2 - test 
    3 - deploy 
    4 
    5 run_test_case: 
    6 stage: test 
    7 before_script: 
    8 - echo "Before script" 
    9 - hostname 
    10 - /bin/bash cleanup.sh 
    11 
    12 script: 
    13 - echo "Main Script" 
    14 - node server.js & 
    15 - sleep 3 
    16 - /bin/bash simpletest.sh 
    17 
    18 deploy_to_production: 
    19 stage: deploy 
    20 script: 
    21 - echo "Run code here to do production deployment" 
    22 environment: 
    23 name: production 

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

enter image description here

enter image description here

+0

Как насчет 'gitlab-ci.yml'? – devo

+0

Одно сомнение, здесь в моем случае обе среды одинаковы (gitlab и построены на одном хосте), поэтому эти шаги не работают для меня. – devo

+0

Я думаю, что у меня должен быть бегун-оболочка, попробовал это, и проблема с клонированием, как я упоминал в разделе обновления сообщения. Бегун использует 'http' для клонирования репо, и он не работает даже в моей локальной системе. – devo

 Смежные вопросы

  • Нет связанных вопросов^_^