Menu Close

Complete Pipeline

This is the fourth (and final) post in a series on creating a deployment pipeline.

The last step in our deployment pipeline is delivery to a server.

Amazon created instructions of how to do it, but before we get far, we need to create a AWS Account.  The Free tier should be sufficient. I created one.

Let’s return to Amazon’s integration description.  I started to follow it, and it’s not for the free tier.  CloudFormation and auto deploying servers means I would be paying Amazon.   Maybe I’ll pay later, presently I want to stick to the free tier.

Also, it’s for Spring Boot, and I’m not interested in Spring Boot. I’m not only being selfish, trying to hold on to my code.  It’s partly my selfishness, but I specifically am not interested in Spring Boot at this time.

A lot of tweaking will be necessary.  The java version is important.  I wish to use java version 18, not 1.8. has instruction on running on a EC2 instance.  We can start with the section Deploy with GitHub Actions instead.
I’ve created an EC2 instance (t2.micro which is free tier eligible) with Ubuntu.  After sudo apt update and sudo apt upgrade,  I can follow Amazon’s Corretto Install docs to get the java 17 JDK installed.

Next I can follow to install a java webserver.

I likely have too much running on the machine.  Another time I’ll secure it.  After running all these commands on my new server, I can see I have jetty running.   Next we want to automatically deploy the war file which GitHub produces for me.

First create a secret in the repo with the .pem file we got when we created the Ec2 instance. Next, create one for the DNS name of the instance. And create one for the contents of my local ~/.ssh/known_hosts file after the first time I ssh’ed into the instance.

My GitHub workflow drops a build.war file into /usr/share/jetty9/webapps which jetty opens and serves at /build on the server.

Having gotten the GitHub workflow going, I have a running server, with an end to end deployment.   In future posts we can look at

  • securing it,
  • putting the webapp at the root,
  • creating monitoring,
  • creating testing whether it’s working,
  • and scripting the t2.micro setup to reduce the manual steps.

 But that’s it for this series. 

Next week I’ll be on a completely different topic.  Do you want more series like this one?  Do you like to watch as I build things like this? Let me know in the comments below.

1 Comment

  1. Alan

    I had forgotten to add roll backs to my list of future work.

    And per client speed limits.

    Some people suggest test and stage environments as well. I won’t include that here, but would definitely be something that could be built atop the GitHub repo.

Comments are closed.