🔑リリースキー

apt-get install ssh
apt-get install openssh-server
/etc/init.d/ssh restart
service ssh restart

keyを生成するために、jenkinsサーバにsshをインストールします.

ssh-keygen -t rsa

次にkeyを生成するコマンドを実行します.
入力したい情報があれば入力すればいいのですが、いずれもEnterに入ることができます.

鍵は正常に生成されます.今、この鍵を원격으로 붙을 서버に渡します.
発行された鍵の位置は/${linux 계정}/.ssh/の下にある.

2つのファイルを確認し、公開鍵を원격으로 붙을 서버にコピーして転送すればいいです.
ファイルをそのままコピーして別の場所に貼り付け、サーバーに貼り付けます.
원격으로 붙을 서버で~/.ssh/が確認された場合、許可されたkeysファイルが存在し、そのファイルに公開鍵の内容がインポートされていない場合、またはファイルがない場合は、名前に従って作成するだけでよい.

👨‍💼 Jekins設定

まずPublicsh over SSHプラグインをインストールします.
インストールされている場合は、インストールする必要はありません.


システム設定にSSH設定が追加されていることがわかります.

keyに私たちが発行した秘密鍵の値を入れます.

SSHを追加し、次のように入力します.
Key:Private Key値を入力
Name:任意に入力可能
Hostname:IPアクセス
Username:IPユーザーへのアクセス
リモートディレクトリ:アクセスはどこから開始しますか?
Jenkins Docker ContainerからDocker Serverを実行するLazBerryFiサーバにコマンドを送信するように設定したので、内部ip番号に接続しました.認証IP:portに接続した後,5回のリクエストのうち1回が成功したという奇妙な結果を得た.

👊テスト

テストパイプラインを作成し、正常に動作しているかどうかを確認します.

pipeline {
    agent any

    stages {
        stage('Test') {
            steps {
                sshPublisher(publishers: [
                  sshPublisherDesc(
                      configName: 'publisher',
                      transfers: [
                        sshTransfer(
                            execCommand: 'sudo mkdir /test'
                        )
                      ]
                  )
                ])
            }
        }
    }
}

「事前構築フォルダ」リストを確認してtestフォルダがないことを確認します.

構築に成功した後

testフォルダが作成されたことを確認できます.

🔨Jenkinsのパッケージングと導入

既存のconfigパイプラインを変更します.

pipeline {
    agent any

    stages {
        stage('Clone') {
            steps {
                git branch: 'main', credentialsId: '8e8302f1-6b98-4bfe-9981-2e027e49089b', url: 'https://github.com/juno-choi/jayeon-config.git'
            }
        }
        stage('Clean') {
            steps {
                sh 'cd /var/jenkins_home/workspace/config'
                sh 'chmod +x gradlew'
                sh './gradlew clean'
            }
        }
        stage('Build') {
            steps {
                sh './gradlew build'
            }
        }
        stage('HUB Push') {
            steps {
                sh 'docker build -t ililil9482/config-server:1.0 .'
                sh 'docker push ililil9482/config-server:1.0'
            }
        }
        stage('Down') {
            steps {
sshPublisher(publishers: [
  sshPublisherDesc(configName: 'publisher',
  transfers: [
    sshTransfer(cleanRemote: false,
    excludes: '',
    execCommand: 'cd /msa/config && sudo docker-compose down',
    execTimeout: 120000,
    flatten: false,
    makeEmptyDirs: false,
    noDefaultExcludes: false,
    patternSeparator: '[, ]+',
    remoteDirectory: '',
    remoteDirectorySDF: false,
    removePrefix: '',
    sourceFiles: '')
  ],
  usePromotionTimestamp: false,
  useWorkspaceInPromotion: false,
  verbose: false)
])
            }
        }
        stage('Up') {
            steps {
sshPublisher(publishers: [
  sshPublisherDesc(configName: 'publisher',
  transfers: [
    sshTransfer(cleanRemote: false,
    excludes: '',
    execCommand: 'cd /msa/config && sudo docker-compose up -d',
    execTimeout: 120000,
    flatten: false,
    makeEmptyDirs: false,
    noDefaultExcludes: false,
    patternSeparator: '[, ]+',
    remoteDirectory: '',
    remoteDirectorySDF: false,
    removePrefix: '',
    sourceFiles: '')
  ],
  usePromotionTimestamp: false,
  useWorkspaceInPromotion: false,
  verbose: false)
])
            }
        }
    }
}

既存のdocker hubにpushを加えた論理には、cocomeを用いてコンテナを往復移動する操作も追加されている.

コンテナは22時間前に開いたので、ジェンキンスに試してもらいましょう.


正常に稼働し、コンテナも正常に再稼働した.
これはジェンキンスサーバからソースコードを抽出し、ソースコードを構築し、jarをdocker hubにアップロードして使用する方法です.ここで私の疑問は、画像化した後、ジェンキンスサーバからソースコードを削除すべきかどうかです.すべて容量がいっぱいになるので、必要なときだけ引いて消したほうがいいのではないでしょうか.
その部分を修正したかったのですが...だめです.理由が見つからない...これからは必ず改善や他の方法があります.ぜひ探してみてください!
挑戦する方法はif test-d/var/jenkins home/workspace/configである.then rm -r/var/jenkins_home/workspace/*; 私はfiコマンドでconfigフォルダが存在するときに削除コマンドを実行したいだけです.だめだよ...理由が分からない.