[Spring Boot2.4.2] .jarファイルにしてvagrantにデプロイしたい

-> Spring Boot Mavenプラグインを追加することで、実行可能なファイルとしてパッケージ化することができる。
-> pom.xmlに追加する

// 省略

run as -> maven install

targetフォルダに demo-0.0.1-SNAPSHOT.jar が生成された


$ java -version
openjdk version “1.8.0_265”
OpenJDK Runtime Environment (build 1.8.0_265-b01)
OpenJDK 64-Bit Server VM (build 25.265-b01, mixed mode)

$ wget https://d3pxv6yz143wms.cloudfront.net/
$ sudo yum localinstall java-11-amazon-corretto-devel-
$ java -version
openjdk version “11.0.2” 2019-01-15 LTS
OpenJDK Runtime Environment Corretto- (build 11.0.2+9-LTS)
OpenJDK 64-Bit Server VM Corretto- (build 11.0.2+9-LTS, mixed mode)
$ rm -rf java-11-amazon-corretto-devel-
$ java -jar demo-0.0.1-SNAPSHOT.jar


What is Blue / Green deployment?

Systems that take a method called Blue/Green deployment have increased.

In place: Reflect only the new revision application on the spot, leaving the instance intact.
Blue / Green: Build and replace a new instance for new revision applications.

And it can roughly classify the following three categories at the reflection speed with another axis different from the realization method.

All at once: Deploy all of them all at once with new revisions.
One by one: Deploy a new revision one by one.
Batch: Deploy a few new revisions(eg half)

There are people often thinking about Blue/Green deployment “only new instances of the revision are constructed by switching to the same number as it is now”, but this kind of deployment method is also called Red/Black deployment in recent years. This is just one way of “deployment at all at once in Blue/Green”

In place
– Merit
Since this method does not require additional instances at deployment, it is very effective in environments where it is not easy to create instances such as on-premises environments. Since it is enough to distribute only the application and restart or the like to the instance where hardware purchase, OS installation and various settings have already been completed, additional instance costs are not required at high speed.

– Demerit
One is tat remote operation is required. Remote operation is to operate on an instance that is running by way of ssh etc. In the case of using ssh, it is necessary to manage the key, so the construction of the instance becomes somewhat complicated, and the risk of opening a hole such as ssh etc. for the instance used in the production environment is reduced as much as possible from the very beginning it is safer to have it. Although we can alleviate this somewhat by using an agent type mechanism like AWS CodeDeploy, we do not change the risk of distributing files or executing arbitrary commands during operation.
Finally it is also difficult to roll back. Consistency is more likely to collapse when returning things that have changed once. “In Place”, there is the fact that you have to maintain two types of deployment, “deploy application” and “deploy under application”.

Blue/Green is not necessarily just switching before preparing the same scale in Blue/Green. The point is that it does not do anything for running, it creates a new revision on another instance and switches over the whole green/blue according to an arbitrary strategy.

– Merit
You can eliminate all the disadvantages of in place mentioned above. First of all, for remote operation, we do not make any changes to the running instance at deployment, so we do not need anything. Instances need not have any mechanisms related to deployment. This also simplifies the application development process.

Regarding consistency, if you create an instance image (Amazon Machine Image(AMI) for Amazon EC2) for each deployment as an extreme way of way of making it, you can guarantee that instances of the same revision are of exactly the same configuration. This is the method that Netflix is taking.

Rollback is very easy. Because Blue does not have any changes in deployment, you simply need to return traffic to Blue. Even after discarding Blue, restoration is also easy if you restart it from AMI of the past revision.

As described above, in Blue/Green deployment is carried out together with “deployment of application” with lower deployment, so for example, it is possible to realize OS updates and the like with exactly the same mechanism, the deployment process becomes one and maintenance also will be much easier.

– Demerit
For example, it is said that cost is high for making AMI for each deployment. Especially it takes time to rebuild from AMI when deploying minor fixes. This can be avoided to some extent by automating the creation of AMI and configuring a CI / CD pipeline that is already ready for deployment. Rather than creating an AMI for each deployemnt, you can keep the AMI of the basic configuration fixed so that you get the latest revision at instance startup, but in that case a breakdown of consistency similar to “In place” care should be taken as it can happen.

Also typically said is the cost of having to make extra instances. Although you wan to make a bit of modification you have to bother to set up an instance, trying all at once will double the cost temporarily, and that is certainly a waste.



通常、関数やメソッドが単体テストの単位(ユニット)となります。 プログラムが全体として正しく動作しているかを検証する結合テストは、開発の比較的後の段階でQAチームなどによって行なわれることが多いのとは対照的に、単体テストは、コード作成時などの早い段階で開発者によって実施されることが多いのが特徴

コードの内容をよく理解している開発者によって、コード作成と同時か直後に(または、『テスト駆動型開発』Test Driven Development:TDD と呼ばれる開発手法ではコードの作成よりも前に)テストケースが作成されるため、妥当性の高いテストケースを資産として残すことができ、後の拡張開発や改修時にも再利用できる