1. kubesphere の開発パイプラインの作成
「Jenkinsfile を使用してパイプラインを作成する」を使用する必要があります。公式ドキュメントを参照してください: Jenkinsfile を使用してパイプラインを作成する
つまり、Jenkinsfile ファイルは git ウェアハウスに存在する必要があります。通常、Jenkinsfile ファイルはソース コードと同じ git ウェアハウスに配置され、git ウェアハウスの第 1 レベルのディレクトリに配置されることに慣れています。
1. パイプラインを作成し、「コード ウェアハウス」---「git」をクリックします。イントラネット上にプライベート gitlab ウェアハウスを構築しました。ここで「git」を選択し、git アドレスと認証情報を入力して、チェック マークをクリックし、「次へ」 」。
2. 以下に示すように、Jenkinsfile パスを設定し、WebHook アドレスを表示します。
ここで WebHook アドレスを覚えておいてください。
「通常のフィルタリング」ではブランチをフィルタリングできます。たとえば、develop ブランチのみを作成する場合は、通常の形式で「develop」と入力します。複数のブランチがある場合は、2 つのパイプラインを作成するのが最善です。そうしないと、複数のブランチが作成されます。同時に発動。(もっと良い方法があれば追記します)
これでkubesphereのパイプライン構成は完了です。Jenkinsfile スクリプト コードの内容:
pipeline {
agent {
node {
label 'base'
}
}
stages {
stage('拉取代码') {
agent none
steps {
container('base') {
// echo "--printenv --"
// sh 'printenv'
checkout(scm)
script {
gitbranch=env.GIT_BRANCH
if(env.GIT_BRANCH=="develop"){
env_name="test"
env_name_big="Test"
}
else if(env.GIT_BRANCH=="master"){
env_name="prod"
env_name_big="Production"
}
}
// echo "env_name=${env_name}"
// echo "env_name_big=${env_name_big}"
// echo "gitbranch=${gitbranch}"
// echo "GIT_COMMIT=${GIT_COMMIT}"
sh '''pwd
ls'''
}
}
}
stage('构建镜像') {
agent none
steps {
container('base') {
// echo "env_name=${env_name}"
// echo "env_name_big=${env_name_big}"
// echo "gitbranch=${gitbranch}"
// echo "GIT_COMMIT=${GIT_COMMIT}"
script {
docker_image_url="${REGISTRY}/${DOCKERHUB_NAMESPACE}/${APP_NAME}:${env_name}${timestr}_${BUILD_NUMBER}"
}
// echo "docker_image_url=${docker_image_url}"
//sh "echo ${docker_image_url}"
sh 'mv ${web_dictionary_name}/Dockerfile .'
sh " docker build --build-arg ASPNETCORE_ENVIRONMENT=${env_name_big} -t ${docker_image_url} . "
echo '镜像打tag完成了'
}
}
}
stage('推送镜像到Harbor仓库') {
agent none
steps {
container('base') {
// echo "env_name=${env_name}"
// echo "env_name_big=${env_name_big}"
// echo "gitbranch=${gitbranch}"
// echo "GIT_COMMIT=${GIT_COMMIT}"
// echo "docker_image_url=${docker_image_url}"
withCredentials([usernamePassword(credentialsId : 'harbor-auth' ,passwordVariable : 'password_var' ,usernameVariable : 'username_var' ,)]) {
//echo '本地镜像上传到harbor---start'
sh " docker login -u ${username_var} -p ${password_var} ${REGISTRY}"
sh " docker push $docker_image_url "
//echo '本地镜像上传到harbor-ok'
}
}
}
}
stage('部署') {
agent none
environment {
env_name_big = "${env_name_big}"
env_name = "${env_name}"
}
steps {
container('base') {
echo "env_name=${env_name}"
echo "env_name_big=${env_name_big}"
echo "gitbranch=${gitbranch}"
echo "GIT_COMMIT=${GIT_COMMIT}"
echo "docker_image_url=${docker_image_url}"
withCredentials([kubeconfigFile(credentialsId: env.KUBECONFIG_CREDENTIAL_ID, variable: 'KUBECONFIG')]) {
sh 'envsubst < ${web_dictionary_name}/deploy/svc.yml | kubectl apply -f -'
}
script {
if(env_name=="prod")
{
// echo "http请求更改版本号"
// echo docker_image_url
sh """ curl -X 'POST' '${version_update_posturi}' -H 'accept: text/plain' -H 'Content-Type: application/json-patch+json' -H 'request-from: swagger' -d '{ "appCode": "${APP_NAME}", "appVersionInfo": "${GIT_COMMIT}", "dockerImageUrl": "${docker_image_url}" }'"""
echo "http请求更改版本号成功!"
}
}
echo "自动构建成功!"
}
}
}
}
environment {
APP_NAME = 'test-api'
web_dictionary_name = 'Test.WebAPI'
version_update_posturi='http://10.120.34.5/api/version/BuildNum'
DOCKER_CREDENTIAL_ID = 'dockerhub-id'
GITHUB_CREDENTIAL_ID = 'github-id'
KUBECONFIG_CREDENTIAL_ID = 'kubeconfig'
REGISTRY = '150.10.1.26'
DOCKERHUB_NAMESPACE = 'default'
GITHUB_ACCOUNT = 'kubesphere'
timestr=new Date().format("yyyyMMdd")
gitbranch=''
env_name=''
docker_image_url=''
}
}
もう 1 つの落とし穴があります。kubesphere のバージョンは 3.2.1 ですが、それより上位のバージョンはわかりません。kubephere メイン クラスターとメンバー クラスターの 2 つのクラスターをデプロイします (webapi で開発されたすべてのサイトはこのクラスターにデプロイされます)。パイプライン作成ページに表示される Webhook アドレスにはメイン クラスターのアドレスが表示されますが、これは実際には間違っており、メンバー クラスターのマスターのアドレスである必要があります。すべての gitlab Webhook のアドレスは、メンバー クラスター マスターのアドレスである必要があります。もちろん、「All-In-One」モードであればそのような問題はありません。
2. gitlabのWebhook設定
先ほど指定した git アドレス (「設定」--「Webhooks」) を開き、kubesphere で確認した Webhook アドレスを URL に入力します。
ここでは「イベントのプッシュ」のみをチェックし、「開発」ブランチ名を入力することに注意してください。
「リクエストイベントのマージ」のチェックを外し、「リクエストイベントのマージ」のチェックを外し、「リクエストイベントのマージ」のチェックを外します。Merge コードが同意を要求すると、Push イベントがプッシュされるため、確認する必要があるのは最初のイベントだけです。
複数のブランチをサポートするには、gitlab で複数の Webhook を作成します。
3. Jenkinsfile スクリプト
ブランチ名、git コミット ID、その他のデータなど、いくつかの git パラメーターを取得する必要があります。最初に環境変数を出力し、そこに関連する値がある場合は、それらを直接使用できます。
sh 'printenv'直接使用できる環境変数がいくつかあることがわかります。
env.BRANCH_NAME //分支名
env.GIT_BRANCH //分支名
env.GIT_COMMIT //git commit id