Как развернуть файл JAR с весенней загрузкой в ​​EC2 с помощью jenkins? - PullRequest
Новая
       16

Как развернуть файл JAR с весенней загрузкой в ​​EC2 с помощью jenkins?

0 голосов
/ 05 мая 2018

Я пытаюсь развернуть приложение весенней загрузки на экземплярах AWS EC2. Я видел много блогов и учебников, объяснил процесс развертывания полностью, что понятно. я изо всех сил пытаюсь сделать непрерывное развертывание или доставку в jenkins, основная особенность которого - изменение имени приложения весенней загрузки или файла jar в это время.

мой трубопровод 

  pipeline {
    agent any

    tools{
       maven 'localmaven' 
    }
    stages {
        stage('Build') { 
            steps {
               sh 'mvn clean package' 
            }
            post {
               success {
                    echo 'Now Archiving...'
                    archiveArtifacts artifacts: '**/target/*.jar'
                   }
              } 
          }


    stage('Deliver') {
        steps {
             sh 'scp -v -o StrictHostKeyChecking=no  -i /var/lib/jenkins/secrets/mykey target/*.jar ubuntu@00.00.00.00:/home/ubuntu'
             sh "sshpass -p password ssh -o StrictHostKeyChecking=no -i /var/lib/jenkins/secrets/mykey ubuntu@00.00.00.00 '/home/ubuntu/start.sh'"
        }
    }
}

}

Запуск и остановка и перезапуск сервера обрабатываются в сценарии оболочки.

мой старт.ш 

#!/bin/bash
nohup java -jar /home/ubuntu/aws-0.0.1-SNAPSHOT.jar > /home/ubuntu/log.txt 2>&1 &
echo $! > /home/ubuntu/pid.file

Это запускает мой сервер отлично и отлично работает ..

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

Ответы [ 4 ]

0 голосов
/ 15 мая 2018

Я должен сказать, что вы должны поддерживать версию своего артефакта в качестве стандартного процесса для развертывания без использования prod и prod. Обычно в среде без поддержки вы можете запланировать версию SNAPSHOT , а в производстве вам следует выбрать версию RELEASE , которую можно сгенерировать с помощью mvn release prepare release perform с помощью maven-release-plugin . Это повысит вашу версию POM для следующих последующих выпусков. Вы можете сохранить свой артефакт в AWS S3 или Artifactory или Nexus (для высокой доступности), например, на машине с Ubuntu, на которую вы ссылаетесь.

Теперь я хотел бы предложить вам добавить еще один этап с именем, например stage ('Release') , где вы должны использовать maven-release-plugin для выпуска версии и сохранения ее по отдельному пути, например

ubuntu@00.00.00.00: / Главная / убунту / RELEASE / $ {версия}

и в соответствии с вашей стадией ('Build') следует скопировать в другой путь, например

ubuntu@00.00.00.00: / Главная / убунту / ПАНОРАМА / $ {версия}

Вы можете выполнить этапы ' Release ' и ' Prod-Deliver ' на основе условного входного параметра вашего конвейера Jenkins. Вот возможное решение для гладкой CICD в вашем случае. 

   pipeline {
    agent any

    tools{
       maven 'localmaven' 
    }
    stages {
        stage('Build') { 
            steps {
               sh 'mvn clean install' 
            }
            post {
               success {
                    echo 'Now Archiving...'
                   }
              } 
          }

        stage('Release') { 
            steps {
               sh 'elease:prepare release:perform' 
            }
            post {
               success {
                    ////
                   }
              } 
          }

      stage('NonProd-Deliver') {
          steps {
               /*
               You can extract the version from pom.xml,replace you project location in jenkins workspace in the below command
               */
               sh 'version=$(echo -e 'setns x=http://maven.apache.org/POM/4.0.0\ncat /x:project/x:version/text()' | xmllint --shell ${YOUR_PROJECT_LOCATION}/pom.xml | grep -v /)'
               sh 'scp -v -o StrictHostKeyChecking=no  -i /var/lib/jenkins/secrets/mykey target/*.jar ubuntu@00.00.00.00:/home/ubuntu/SNAPSHOT/${version}'
               sh "sshpass -p password ssh -o StrictHostKeyChecking=no -i /var/lib/jenkins/secrets/mykey ubuntu@00.00.00.00 '/home/ubuntu/start.sh nonprod $version'"
          }
      }

       stage('Prod-Deliver') {
        steps {
              /*
               For production release you should pass the version as a parameter to your jenkins pipeline which is going to be in production
               */
             sh 'scp -v -o StrictHostKeyChecking=no  -i /var/lib/jenkins/secrets/mykey target/*.jar ubuntu@00.00.00.00:/home/ubuntu/RELEASE/${version} '
             sh "sshpass -p password ssh -o StrictHostKeyChecking=no -i /var/lib/jenkins/secrets/mykey ubuntu@00.00.00.00 '/home/ubuntu/start.sh prod ${version}'"
        }
    }

}
}

Вы должны добавить условие в файл скрипта, как показано ниже 

#!/bin/bash
release_type=$1
version=$2
if [[ ${release_type} == "prod" ]]; then
  # non snapshot release to production env
  nohup java -jar /home/ubuntu/RELEASE/${version}/aws-0.0.1.jar > /home/ubuntu/log.txt 2>&1 & 
else
  # snapshot release to non production env
  nohup java -jar /home/ubuntu/SNAPSHOT/${version}/aws-0.0.1-SNAPSHOT.jar > /home/ubuntu/log.txt 2>&1 &
fi
echo $! > /home/ubuntu/pid.file
0 голосов
/ 05 мая 2018

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

#!/bin/bash
nohup java -jar /home/ubuntu/$1 > /home/ubuntu/log.txt 2>&1 &
echo $! > /home/ubuntu/pid.file

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

0 голосов
/ 09 мая 2018

Вы можете просто переименовать файл, когда вы делаете SCP 

scp filename username@remote.host.net.:filenewname

В вашем случае что-то вроде этого 

sh 'scp -v -o StrictHostKeyChecking=no  -i /var/lib/jenkins/secrets/mykey target/*.jar ubuntu@00.00.00.00:/home/ubuntu:aws-0.0.1-SNAPSHOT.jar'

Приведенный выше код берет любую версию сборки, созданную jenkins, во время ее копирования и переименовывает ее в «aws-0.0.1-SNAPSHOT.jar», поэтому вам не нужно изменять свой start.sh

Обычно P.S при развертывании окончательной сборки (JAR) гарантирует, что в качестве имени файла добавляется только имя jar, а не "-0.0.1-SNAPSHOT"

Надеюсь, это поможет:)

0 голосов
/ 05 мая 2018

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

Поскольку я вижу, что вы используете весеннюю загрузку, вы можете сохранить информацию о версии сборки, используя build-info goal spring-boot-maven-plugin, как показано ниже. 

  <build>
    <finalName>your-artifact-name</finalName>
    <plugins>
      <plugin>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-maven-plugin</artifactId>
        <executions>
          <execution>
            <goals>
              <goal>build-info</goal>
            </goals>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

и доступ к информации о сборке Maven через конечную точку привода http://localhost:8080/actuator/info.

Или, Вы можете получить информацию о версии, сохраненную в classpath:META-INF/build-info.properties, просмотрев файл jar, используя следующую команду. 

$> unzip -qc your-artifact-name.jar META-INF/build-info.properties
#Properties
#Fri May 04 17:43:06 IST 2018
build.time=2018-05-04T12\:13\:06.225Z
build.artifact=your-artifact-name
build.group=com.example
build.name=your-artifact-name
build.version=1.0.0.SNAPSHOT

Таким образом, версия сборки не изменяется даже при случайном переименовании файла.

...