Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Continuous Delivery for Microservices on EC2 With mu

DZone's Guide to

Continuous Delivery for Microservices on EC2 With mu

You can deploy mu projects directly to AWS EC2 instances for microservices without containers. Learn how in this tutorial for CD with mu.

· Microservices Zone ·
Free Resource

Containerized Microservices require new monitoring. Read the eBook that explores why a new APM approach is needed to even see containerized applications.

If you want to get into microservices, but aren't ready to take the container plunge, you can deploy mu projects directly to AWS EC2 instances. Using mu's EC2 mode, you can leverage the benefits of microservices without containerization, and speed up development feedback loops.

The web app in this article is the smallest possible Flask application. You can adapt this example to deploy other applications that include their own web servers, like Django, NodeJS with Express, Ruby with puma/thin/passenger, Jetty or even Spring Boot.

Stelligent mu is a great open-source tool to deploy Microservices to the AWS cloud. It has three modes of deployment:

  • AWS ECS - (Elastic Container Service, which runs Docker containers on EC2).
  • AWS Fargate - (A simpler "serverless" version of ECS)
  • AWS EC2 instances without Docker containers. This is the mode we're covering in this article.

In this post, we're going to:

  • Fork this example repository on GitHub.com
  • Change the mu.yml to point to your fork
  • Create the mu pipeline
  • Walk through the resources mu creates for you, and
  • Explain the role each file plays in deploying the app.

Technologies Used

Prerequisites

  • An AWS Account
  • a Github Account
  • a Github Token - create one here
  • AWS Access keys set up in $HOME/.aws

Make Your Own Repository

  • Fork this repository in GitHub.
  • Clone your forked repository to your workstation:git clone git@github.com://mu-minimal-ec2.git
  • Go to the newly cloned directory cd mu-minimal-ec2
  • Edit the repo: line 17 of mu.yml, to match your new repository's URL.
  • Commit and push your changes
    git commit -a -m "modify the repo: attribute in mu.yml"  
    git push
  • Create the mu pipeline mu pipeline up -t

Walkthrough of the mu Pipeline

The mu pipeline up command creates the CloudFormation stacks for the CodePipeline, CodeBuild and CodeDeploy services.

Navigate to the CloudFormation console, and watch the pipeline stacks form. They'll look something like this:

Once the pipeline stacks are created, open the CodePipeline console. You should have one pipeline listed. Click on it.

The mu pipeline looks like this:

  • Source - the CodeBuild service retrieves a copy of your source code from GitHub or AWS CodeCommit.
  • Build - your software is built, tested, packaged according to instructions in your repo's buildspec.yml file. This uses AWS CodeBuild.
  • Acceptance - a new environment called "acceptance" is created (or updated) with your software. This uses AWS CodeDeploy.
  • Production - after the one-and-only manual step, which is to offer Red and Green buttons to stop the pipeline, or deploy the software that is in Acceptance to the last environment, which is Production. This also uses AWS CodeDeploy.

Once the pipeline stacks are complete, you can watch the CodePipeline execute. The CodePipeline/CodeDeploy/CodeBuild services start building your software within a few moments.

When your pipeline reaches the Deploy stage, the CodeDeploy service creates Infrastructure stacks for each Environment, and will update them with each subsequent build. This is another core concept in DevOps known as infrastructure-as-code, and is fully implemented by mu pipeline.

The additional environment stacks look like this:

The infrastructure created by these additional stacks include:

  • networking: VPC, subnets, security groups
  • compute: EC2 instances (alternatively, ECS and Fargate are also supported in )
  • storage: S3 buckets supporting the build artifacts
  • resiliency: AutoScaling groups and the Elastic Load Balancer definitions come with by default.

This means that if you want to change your infrastructure (AutoScaling parameters, your EC2 or RDS instance sizes, etc), you can implement those changes the same way you do your code changes: Change a file, run git add, git commit, and git push!

Walkthrough of the Files

mu.yml

namespace: min-ec2
environments:
- name: acceptance
  provider: ec2
- name: production
  provider: ec2

service:
  name: min-ec2
port: 8080
  healthEndpoint: /
  pathPatterns:
  - /*
pipeline:
  source:
   provider: GitHub
    repo: stelligent/mu-minimal-ec2

Naturally, this example of usage starts with a . There are two sections: one for environments, and one for service s.

The environments: section from lines 2 to 6 (above), are a simple list of the environment names you wish to have (acceptance, staging, sandbox, demo, production, whatever). The provider value can have one of three different values ( ec2, ecs, and fargate).

To learn more about other configuring mu environments, refer to the wiki page for Mu Environments.

The services: section is from lines 8 to 17 (above), and specifies just the bare necessities. We're going to accept incoming connections on port 80, route them to our application on port 8080, checking the / endpoint for 200 OK responses, and use the code in the repo specified on line 17.

To learn more about configuring mu services, refer to the wiki page for Mu Services

buildspec.yml

version: 0.2

phases:
   build:
     commands:
       - pip install Flask

artifacts:
   files:
    - "**/*"

 mu  uses AWS CodePipeline, CodeBuild, and CodeDeploy to turn your github repo into a deployed service. The buildspec.yml contains instructions (lines 3-6), on how to install prerequisites, how to invoke the build, do any postprocessing (minification, compression, archiving, etc).
å

Finally, you specify what files are to be deployed via the artifacts/files: section from line 8 to 10.

You can (and should) also use buildspec.yml to run unit tests. Make sure all your commands return non-zero if there are any failures.

hello.py

  from flask import Flask
  app = Flask(__name__)

  @app.route("/")
  def hello():
     return "Mu minimal ec2 example, v2!\n"

In this example repo, we have included the smallest possible Flask application possible, predictably named hello.py. It listens on a port number and responds to incoming GET / requests with a hardcoded string.

So, now we just needs to tell the system how to install it, start it, and stop this service.

 appspec.yml 

    version: 0.0
    os: linux
    files:
     - source: ./hello.py
       destination: /home/ec2-home/hello/
     - source: ./etc/init/mu-minimal-ec2.conf 
       destination: /etc/init/

    hooks:
     BeforeInstall:
       - location: codedeploy/remove_previous_install.sh
         timeout: 30
     ApplicationStop:
       - location: codedeploy/stop_server.sh
         timeout: 30
     ApplicationStart:
       - location: codedeploy/start_server.sh
         timeout: 30

The appspec.yml file contains the commands that install, start and stop the service.

  • The files section tells the system which files to move, and where they should reside.
  • There are hooks section, with hooks called BeforeInstall (line 8), ApplicationStop (line 11), and ApplicationStart(line 14). Each hook has a script location and a timeout in seconds. These scripts reside in a codedeploy directory, primarily to keep the root directory a little cleaner.

./codedeploy directory

  • codedeploy/remove_previous_install.sh removes /home/ec2-user/hello/hello.py and /etc/init/mu-minimal-ec2.conf.
    #!/bin/bash -xe
    /bin/rm -rf /home/ec2-home/hello* /etc/init/mu-minimal-ec2.conf
    exit 0
  • codedeploy/start_server.sh tells upstart to start the service.
    #!/bin/bash -x
    set +e
    stop mu-minimal-ec2
    start mu-minimal-ec2
    exit 0
  • codedeploy/stop_server.sh tells upstart to stop the service.
    #!/bin/bash -xe
    stop mu-minimal-ec2
    exit 0

Use Your New Application

Use mu env show acceptance to display key information about your app. One of the attributes is the ELB endpoint.

Conclusion

This repository demonstrates using to deploy software to EC2. You should also know that this is just one of several deployment models that supports. can also dockerize your application and deploy it to AWS Elastic Container Service (Amazon ECS) and AWS Fargate. For the latest developments, you can watch the mu repository.

Now that you got your microservice running on EC2, you should know that EC2 can be more expensive than ECS/Fargate in the long run. To take advantage of ECS and Fargate, you will have to learn a bit about creating a basic Dockerfile. There are other mu-related pages about deploying Microservices to AWS ECS and AWS Fargate.

Stelligent engineers also staff a live chat/support forum at gitter.im/stelligent/mu. You can also read through the mu wiki or file an issue.

Discover how to automatically manage containers and microservices with better control and performance using Instana APM. Try it for yourself today.

Topics:
microservices ,ec2 ,continuous delivery

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}