본문 바로가기
[AWS]/GITLAB

63장. AWS CLI를 사용하여 AWS Elastic Beanstalk에 Java 애플리케이션을 배포하는 방법

by SAMSUNG CLOUD-OKY 2022. 3. 2.
반응형

 

## ElasticBeanstalk CLI 명령어

https://docs.aws.amazon.com/cli/latest/reference/elasticbeanstalk/

 

elasticbeanstalk — AWS CLI 1.22.64 Command Reference

Note: You are viewing the documentation for an older major version of the AWS CLI (version 1). AWS CLI version 2, the latest major version of AWS CLI, is now stable and recommended for general use. To view this page for the AWS CLI version 2, click here. F

docs.aws.amazon.com

 

 

## S3 로 파일 업로드 성공

 

 

## cars-api-v26.jar --> ElasticBeanstalk 으로 배포 실패

 

 

 

 

 

 

 

## .gitlab-ci.yml  (오류발생)
- 새로운 애플리케이션 버전 생성
- 환경 업데이트 

variables:
  ARTIFACT_NAME: cars-api-v$CI_PIPELINE_IID.jar
  APP_NAME: cars-api

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: openjdk:12-alpine
  script:
    - ./gradlew build
    - mv ./build/libs/cars-api.jar ./build/libs/$ARTIFACT_NAME
  artifacts:
    paths:
      - ./build/libs/

smoke test:
  stage: test
  image: openjdk:12-alpine
  before_script:
    - apk --no-cache add curl
  script:
    - java -jar ./build/libs/$ARTIFACT_NAME &
    - sleep 30
    - curl http://localhost:5000/actuator/health | grep "UP"

deploy:
  stage: deploy
  image:
    name: amazon/aws-cli
    entrypoint: [""]
  script:
    - aws configure set region ap-northeast-2
    - aws s3 cp ./build/libs/$ARTIFACT_NAME s3://$S3_BUCKET/$ARTIFACT_NAME
    - aws elasticbeanstalk create-application-version --application-name $APP_NAME --version-label $CI_PIPELINE_IID --source-bundle S3Bucket=$S3_BUCKET,S3Key=$ARTIFACT_NAME
    - aws elasticbeanstalk update-environment --application-name $APP_NAME --environment-name "production" --version-label=$CI_PIPELINE_IID

 

 

 

## .gitlab-ci.yml (오류해결) 및 IAM 권한 추가 필요

variables:
  ARTIFACT_NAME: cars-api-v$CI_PIPELINE_IID.jar
  APP_NAME: cars-api

stages:
  - build
  - test
  - deploy

build:
  stage: build
  image: openjdk:12-alpine
  script:
    - ./gradlew build
    - mv ./build/libs/cars-api.jar ./build/libs/$ARTIFACT_NAME
  artifacts:
    paths:
      - ./build/libs/

smoke test:
  stage: test
  image: openjdk:12-alpine
  before_script:
    - apk --no-cache add curl
  script:
    - java -jar ./build/libs/$ARTIFACT_NAME &
    - sleep 30
    - curl http://localhost:5000/actuator/health | grep "UP"

deploy:
  stage: deploy
  image:
    name: amazon/aws-cli
    entrypoint: [""]
  script:
    - aws configure set region ap-northeast-2
    - aws s3 cp ./build/libs/$ARTIFACT_NAME s3://$S3_BUCKET/$ARTIFACT_NAME
    - aws elasticbeanstalk create-application-version --application-name $APP_NAME --version-label $CI_PIPELINE_IID --source-bundle S3Bucket=$S3_BUCKET,S3Key=$ARTIFACT_NAME
    - aws elasticbeanstalk update-environment --application-name $APP_NAME --environment-name Carsapi-env --version-label $CI_PIPELINE_IID

 

 

 

 

 

 

=======================================

 

The next step in the process would be to use the IWC ally to deploy this new version that we have just

uploaded and unfortunately, this is not as easy as copying a file from one side to the other.

I need to explain a few things in order to deploy to IWC Elastic Bienstock, we need to do two things.

First of all, we need to create a new application version.

And second of all, we need to update the environment.

Let me quickly remind you what these terms mean.

One application is called API, and we have created an environment called production later we'll have

other environments as well.

Now for this environment production, we have a running version.

You will see this is a sample application.

One doesn't really matter just to keep in mind that there are different versions.

This is why we need to make these two steps to create an application version and then to update the

environment with the application version that we have just created.

Going back to our pipeline configuration, there are a few things that we can improve.

Now, you have noticed that we have used the artifact name here and again here and here.

So every time we start duplicating things in our configuration, it's always a good idea to think about

using a variable.

This is exactly what we're going to do next.

I'm going to copy this name.

And before stages, I'm going to define variables.

And the first variable, I'll call it artifact name, because this will be the name of our artifact.

And everywhere where the artifact cars appeared, that car was present, I'm going to replace it with

this variable.

Because previously I have mentioned versions, it would really make sense to give this artifact name

sort of like a variable name instead in the sense that it should contain a version as well.

If you remember, it comes with a huge list of prettified environment variables.

And one of these variables is SII, underscore pipeline, underscore idee.

Now, there are at least two options of these you can use to underscore on this caller ID, and this

will be an unique I.D. to the current pipeline that Gottleib uses internally.

And the other one, which I d is unique I.D. that it's coalbed to the project.

So I'm going to take a look at this and see how that goes.

Of course, you are free to use any environment variable that you feel that matches your need.

This will be a simple idea that will be incremental, at least not directly incremental, but it will

be larger than the previous one.

So this will tell you if a version is newer or older than the previous version.

In this day and age, keeping track of versions as we used to do in terms of semantic versioning like

version one, version two, version three and so on, it's not really a requirement anymore.

And simply having a unique idea which can help you identify which version of the project is deployed

on the server, it's still good enough in order to get Destrehan.

So I'm going to call that this is fresh and in this core idea, that's what you do with a WASC ally

and see how we can deploy this.

Now, as I mentioned, the first step is to create application version.

So this goes like a WSC Elastic Bienstock create application version with dashes between the.

An experiment that we need to provide is application name.

Because our obligation is cast API, it would make sense to put this in an environment variable as well.

Initially, we're going to give our version label sort of like a back to this version that we can easily

identified because we're already using a variable from Getler, we're going to use the same variable

that we have used for version.

Now finally comes the part where we reference what we have updated in our S3 bucket and practically

a W.S. Elastic Bienstock, hey, take this artifact, take this file that we have and use this in order

to create this application version than the instructions for this will be this dash source.

Dash bundle.

And this will be S3 Buckett.

And then to give the variable that we have used for the S3 bucket.

And he saw the identifier for what you are trying to upload will be the S3, he.

This will be the artifact name.

So it is command, it will know to get this information from the S3 Buckett, which has this S3 Ketso,

get the object old what we have called it, Khazei Peja, when the specific version and create the new

version we did.

Now, this in itself will not change what is being deployed.

What is currently executed on the production side of it will just create a new version, but that version

will not be active.

So for that reason we need to execute.

Another command in this command is called a W.S. That's the Bienstock.

Update environment.

The application name will be the same.

The environment name will be production.

And finally, we have again, diversion label, but we can see that a few informations are still similar

to the previous one because we need to have a relationship between what have we created for an application

version and what do we want to actually deploy.

Because what update environment will do is we'll take this version that we have uploaded, practically

deployed, make it live.

OK, so I don't think the label needs to be equal here.

And finally, in the big process, there's still a small change that we need to do so far we have assumed

that artifact will be called that Daija, and this is how the artifact will be built.

But it doesn't mean that we can keep it this way because now we have a variable name and we need to

rename the artifact as well.

So in order to rename that, we're going to use the move command and we're going to do is to move the

file from built lips, car dash API, Daija to build lips.

And then this will be the artifact.

This is hardcoded in the project.

So this is why this has to stay this way.

And we still need this extra step to commit and see how the deployment goes.

 

 

 

반응형

댓글