Posts in CI/CD

Build and deploy Flask app to EKS

CI/CD DevOps Kubernetes

Here’s an example of how to adopt DevOps approach in your development process.

Code your application

In this example we’ll use Flask to build a website and you can adopt this approach to any programming language

This app is simple Flask (video link bellow) with one route that returns index.html file.

Build your application

Once the current version is ready you can build the project, the pipeline should include build and tests.

If you’re using Static-typed language then you’ll need to compile the application before building the container image and then copy the artifact to the image.

For Dynamic-typed languages there no compile so it’s just building the container image using CI pipeline.

Deploy your application

To keep a software product updated and maintained, the deployment process should be on-demand and easy (click a button).

This code > test > deployment should be repeated for every code change.

What can be accomplished here?

By doing the work (coding) and implementing a deployment process the gap between development and production is resolved and the outcome is faster software delivery (CD) with reliable code (tests).

So DevOps is an approach and a way to build software.

Check this video tutorial for E2E build and deploy Flask website to Kubernetes cluster (EKS).

Cloud Native

CI/CD Continuous Delivery Deployments DevOps system architect

How does your team is working with cloud infrastructure?

Cloud Native Topics

  • Development process
  • System design
  • Builds and packages
  • Deployments
  • Release
  • Cloud infrastructure

Development process

When working with cloud systems the proven methods to develop and run applications in production is DevOps

DevOps is the practice of code > build > test > deploy > release > repeat

DevOps is about bridging the gap between development to production

System design

You can use different methods of designing applications but if your applications are stored in the cloud then Microservices might be better to implement, otherwise why use on-premise approach when you can enable the benefits of using cloud infrastructure?

Builds CI and packages

Containers by now are the default approach to build applications as its comfortable to ship and deploy

Its easy to start local development environment using containers and work on your application

CI is an integral part as this will initiate your committed code to get build and get deployed

Deployments

Deployments to production is easier when the application is packaged as a container image

This is the next step after builds as this is the confirmation that the tests are ok and the container image with the latest code already pushed to the image repository and ready for deployment to production

Release

This is the step after the deployment is successful and the new image is used in production

Now the choice is when to enable new features using feature-toggle

Once the new features are enabled the release step is complete

Cloud Infrastructure

To manage the containers and successfully implement Microservices you’ll need Kubernetes cluster to orchestrate the containers runtime

Other services like sending email, databases, load balancers and more, can be integrated with your Kubernetes cluster to be used for the entire stack

Summary

Cloud Native is proven to have better results and happy developers

but Hey! you can always start a long running VM and install some stuff on it

How to deploy production systems

CI/CD Continuous Delivery Deployments DevOps

In some situations development teams are deploying some of the production systems from local, yes from their local laptops. that’s is a not recommended practice as it causes issues in prod.

Why developers modify from their local laptop?

There can be a few resources for why deploying new code and modifying production config is done from local laptop, here are a few examples

  • No CI pipelines
  • Failed CI pipeline
  • Just bad practice

In any case it is not recommended to modify production systems from local laptop and it’s better to use CI tools.

How to modify production systems?

When you update production with new code/config or new services the downtime should be zero.

for a successful deployment to production you’ll need to adopt a few approaches

Git Ops

In summary this means that every modification will be committed to your Git repository.

Infrastructure as code

In summary this means that the creation and update of the infrastructure should be declared in code/template.

CI Pipeline

When a commit is made to the relevant repository Git sends a hook to the CI system to start the CI pipeline, this will initiate: build > test > deploy

when the CI pipeline is complete we know that the build, tests and deploy successfully as expected. (DevOps outcome should be expected for every pipeline)

Note: there’s another step of release that “enable” the actual new code, and this is done via feature toggle.

Deployment to production

This is where the deployment strategy comes, obviously force-deploy will shutdown the services and start the services again (downtime)

we’ll need a better approach like blue-green that will create another group of resources with the new code and only after its active the current requests/traffic will be redirected to the new group of services.

after the deploy is OK the old resources can be deleted.

Debugging

To verify that the deploy is OK

  • check your metrics and logs
  • check that the service is operational (can be done via automated QA)

Summary

Do not be tempted to deploy from local laptop as this will cause issues and it will not be registered in logs or as a commit.

Use CI pipeline!

Continuous Integration In Production

CI/CD

What is CI? and How to implement it in production?

CI – Continuous Integration

CI is the practice of activating automated pipelines for testing and building processes.

The automated build includes the following:

  • Testing to verify code reliability and desired result from the developed feature or bug fixes.
  • Compiling the source code to an artifact.
  • Building the source code to a docker image.
  • Additional tests with other software components may also be included in the pipeline.

CI Feedback

When a developer commits code that is activating a CI pipeline the feedback is generated.

Based on that feedback (pipeline log output) the developer knows if there are issues or the pipeline succeeded and is ready for deployment to production (Continuous Deployment).

The log includes the various steps to ensure the code is reliable and software is doing what its designed to do.

CI Before CD

To ensure a successful deployment to production the CI pipelines are extremely important as it is the verification process for the development stage.

Integrating CI pipelines for the entire applications will ensure an expected result for every new code in development.

SpinningOps helps startups improve their system design, contact HERE and ask what can we do for your application.

Bots As Part Of Your Cloud Ops

CI/CD Cloud Security DevOps system architect

Do you have bots in your stack?

How do you assign permissions to a bot?

Bots in the context of your cloud ops

I’ll explain, let’s say you use Jenkins for your CI/CD pipelines, how does Jenkins clone new code from the code repository?

Or how does your Slack channel receives alerts from an app?

Sometimes you need bots in your stack but here’s the challenge, what permissions does a bot gets?

Let’s start with naming your bot

A good practice is to name the bot as what it’s supposed to do, for example:

  • bot-jenkins
  • bot-slack
  • bot-s3-read-only
  • etc..

you get the point, start the naming with bot so other people won’t confuse it with other users.

What about naming policies?

I set the same naming for permissions and policies, it’s very easy to manage something that you know what it is and what it does by it’s name

Keys or Roles?

I prefer using Roles, it’s better than just putting a secret somewhere not knowing who use it

but there might be a situation where you’ll need to use keys, for example if you need to rsync files from a remote server on a different cloud vendor than Roles is not an option, just make sure those keys have the exact permissions it needs for the task

Once the task is done deactivate the keys

Summary

Bots are part of your stack so add the exact permissions for the specific task

Build, Test, Deploy. the hello world of CI/CD

CI/CD DevOps

When you start at programming the traditional first program you learn to write is: hello_world() and it became quite common on every programming language you choose to learn.

The hello world of CI/CD

In CI/CD you probably noticed the term build > test > deploy > repeat and this is the hello world in DevOps.

But what does it means?

so let’s assume your code is in Python, then there’s nothing to build unlike Go (golang) so why do you need build stage?

Let’s start from end to start

let’s assume your app is already deployed and running at your cloud of choice, how do you update your app to a newer code?

  • first build your code, why build? because it’s easy and convenient to use and deploy on different environments and can be reused or rollback if needed.
  • second test your code, why test? because you want to ensure your app runs without problems or bugs (making sure code does what it needs to do)
  • third deploy your new code (new version), so the users that use your app can have the new features or the newer bugs (that’s a joke) available for use.

How do you write your first CI/CD hello world?

  1. write code in your prefer language of choice
  2. build it via docker, and have a docker image from it (use tag for versions)
  3. run tests on the functions of the code using the built image (from step 2)
  4. deploy the new image after a successful test via docker with new image tag

so have fun with CI/CD and solve this problem for your company

How many stages do you need for a Jenkinsfile

CI/CD DevOps

You need to build a new Jenkinsfile / pipeline to build and test an application or a feature, so how many stages / steps do you use?

Also do you need a few stages or one stage is enough?

Here is where your approach comes to play, there are two main approaches I noticed in workflows from people

1st option: one stage to build and deploy

let’s assume you need to build an artifact from your code so one stage can be enough, something like: build your artifact > deploy (upload to your repository)

this approach will complete a couple of goals

  1. your code is built automatically via scripted job and if the build passes you know part of the code is OK, will it deployed successfully on your server? maybe, so you may want to add install stage before deploying.
  2. once your code built now it’s the easy part to upload the artifact to your repository or registry if it’s a Docker image.
    so it’s easy to understand and because it only two stages it’s faster to complete but you might want more options to integrate in your build.

2nd option: many stages to build, test and deploy

this approach will probably cover most of your software needs

  1. you build your code and once it’s done you start the second stage and start testing, now you don’t need a test to build because that already being done so you can add the installing stage and just deploy your artifact on a docker machine to verify it can be installed as predicted.
  2. once your artifact is installed you can continue to the next stage and add more test in a separate stage, here is where you might want to add commands to check some functionality that your code needs to do.
  3. after the first phase of your tests is completed you can add another stage to deploy your artifact after install to a light environment like Docker or a testing server (Jenkins agent) and make an API call to test some functions to verify that your code is working as expected.
  4. Now it’s where the parts come to play together, add another stage of tests to make sure your code can integrate with 3rd parties like Email, Slack or external API

once your tests are OK it’s deploy time

Time to deploy your code / artifact to your production server, it is recommended that you deploy it first to a staging server, just to make sure you didn’t miss anything, staging will run with your new code just a few minutes before deploying to production.

once everything is OK with your staging deploy to prod, a few options here:

deploy your code instead of the current version, until your deployment will complete your service will probably be unavailable temporary.

add another server to your servers group with the new version and once is OK remove the old version from the old server.

if your app have considerable traffic you might want check deployment tools like Spinnaker to deploy a canary approach of your app.

P.S.

use your approach based on your app needs and traffic

Continuous delivery in a bite

CI/CD Continuous Delivery DevOps

Continuous Delivery AKA CD is a set of practices that aim to build > automate > release software cycles.

CD is about delivering software to the end-user as fast as you can it’s a challenge due to best practices and other software concerns.

Benefits of CD

Let’s go over a few benefits you can achieve in your CD process/workflow.

Faster time to deliver software

Once your development team agrees on a CD “plan” something that works for your product and company and you have “field-tested” it, you’ll have faster build and release cycles.

Better teamwork in the development

Again let’s use the word “agreed” which means your development team has a plan and a system to accomplish a version release cycle, your development team will work better towards that goal of developing and releasing new software, why? fewer arguments, people know the workflow, and stuff gets done.

Lower costs (in theory)

Let’s assume you have the best optimal workflow for your development team, now that your development cycles are working fairly faster the costs may be lower, less compute resources, fewer meetings, and more efficiency.

Faster reach to market

So this is more of a business aspect but is depended on product development, if your product development is fast meaning you can release versions of your product (in this case software) faster then you can deliver faster features and products thus giving you the advantage over competitors that have a slower rate of product release.

How to automate jobs using Jenkins agent

CI/CD Continuous Delivery DevOps

Do you maintain Jenkins agents for your jobs? does your Jenkins agents running while in idle?

What if you could start a Jenkins agent for every job you run at Jenkins, and the best part no need to maintain and keep a Jenkins agent like a long-running server.

So how do you automate your jobs?

  • Start with installing the EC2 and Cloud plugins in your Jenkins server.
  • then configure Jenkins to run jobs only at agents and not on the master.
  • start a new job and a new instance will start (I’m using AWS so an instance will be initialized on that EC2 cloud)
  • wait for about 5-10 (it varies) until the agent is connected and watch the job run at that specific agent/node.

also you can configure the Cloud plugin to terminate the Jenkins agent once the agent is in idle for “x” amount of time, depends how many jobs you run every hour.

The outcome

If you use this approach you can save on cloud costs and automate jobs

P.S. you can configure spot instances to run as Jenkins agents.

Do you want to automate your Jenkins agents?

I can automate your Jenkins agents for you, contact me today HERE

How to deploy S3 hosted website

CI/CD Deployments

When you have a website that is hosted at S3 updating new version of this website can interrupt with your regular tasks so how can you automate this repeating upload of new website version?

Jenkins as your automation

Jenkins can do many things including automation for this specific task of deploying new version of your website, thus making the operation of new version upload automatically.

how to automate your new version deployment?

  1. Create a git repository for your website
  2. Create a new pipeline in Jenkins using the Jenkinsfile here
  3. Start the job or commit a new version to the website repository

P.S. don’t forget to check the option in the job:

GitHub hook trigger for GITScm polling

Example of deployed website

Check out this example of a website that is automated via Jenkins here

Summary

Now you can add more tasks to your automation and create new automation jobs