Managed Kubernetes platforms make it easier to manage your Kubernetes infrastructure, and if you’re already using AWS, you might want to test drive EKS. EKS has been in GA since the early summer of 2018, and offers a pretty straightforward setup guide to set up your first cluster.
A few weeks ago, I gave a presentation on developing a Kubernetes app with EKS and CodeShip to a DevOps.com audience. You can check out the recording for yourself, or you can view the slides via SlideShare. [Tweet “”Build a Kubernetes App with EKS and CloudBees @CodeShip””]
If you want to follow along with the examples, the source code is available on GitHub. I’ve also compiled some of the top questions from the Q&A and answered them below. Enjoy!
Does EKS have the ability to pull from a custom docker registry (e.g – artifactory) ? Yes, you can use any registry with your Kubernetes application running on EKS, but you need to make sure it’s configured for access. For example, you can use Artifactory with EKS.
Can CodeShip can also be used with AKS or only with EKS/DockerHub? You can use CodeShip with any deployment target, for any type of app. Kubernetes and other containerized apps are well-supported on the platform, but CodeShip also works well if you’re using a different orchestrator like Docker Swarm, or even if you’re not using containers yet. You can use any image registry with CodeShip.
Can we use something else apart from CodeShip, like CodePipeline from AWS? Definitely. You can deploy to EKS using any CI/CD tool, though you might find that some of them have features that better support the tasks you need to complete in order to update your Kubernetes application, like building and pushing container images.
Can you enumerate some benefits for CodeShip over other CI/CD solutions? – Extremely fast builds via Docker Image Caching – Simple and intuitive, easy to set-up – Full control and customizability of CI/CD workflow creation user container technology – Empowers lean teams without access to shared service team that maintains CI/CD to achieve highly scalable and fast software test and delivery automation
How do we import existing Kubernetes or Docker containers on premise to EKS? It really depends on your application. The container image is the heart of your application. There are a lot of things to consider when migrating workloads (like what to do with persistent data and generally how to deal with state). But the first step is getting the EKS cluster up and running, and then making sure it can access the registry where your container images are hosted. You’ll also need to make sure your deployment systems can access the cluster.
How do we manage the authentication and authorization in term for new users? Access to EKS is managed via AWS IAM users and roles, so they will need credentials from AWS itself in order to access your cluster.
How do you promote from staging to production? There are countless ways to do it, and the right solution for you will depend on the needs of your application and team. Many teams have a staging environment that corresponds to a
staging branch in their project repository. Production corresponds to
master. If you have stricter requirements, you might want to look into a tool with promotion policies like Docker.
How is CodeShip different from Jenkins X? CodeShip is a hosted CI/CD SaaS that is technology agnostic, that balances ease of setup with powerful flexibility. It is fully managed and optimized for extremely fast builds and turnkey deployments for multiple applications. Jenkins X is an open source project for deploying Kubernetes apps using a GitOps workflow. Because it is unsupported you must manage it yourself. With CodeShip you can focus on writing great code and not worry about maintaining infrastructure.
How can you rollback a deployment? Kubernetes offers pretty good support for deployment rollbacks out of the box. The docs are pretty comprehensive.If you want to rollback outside of Kubernetes itself, you can use things like the “Revert PR” feature in GitHub. For a bit more fine-grained control, CodeShip has
on_fail step types that can run e.g. a cleanup script if the preceding step failed.
Is there any timeout in the manual approval process to cancel the build and abort the push to the master? There’s no timeout — someone with permissions to manually approve or reject a build needs to take action to either abort the build process or approve it.
Is there any configuration changes required for microservice deployment? It depends on your application. Your configuration needs to match your application’s needs, so you need to make sure that all of your microservices are packaged as container images and can be deployed. Testing against a local cluster is a good way to test your configuration.
Why is the manual deployment triggering the build and push stages again? I set it up that way, but you can create a manual step anywhere in the build process. It basically just suspends your deployment workflow until someone with the correct permissions approves or rejects the build. In this case, I used it to have a check before deployment, but you can use it for other things, like running tests with Percy.io, or having QA approve or reject a build after verifying changes in staging. [Tweet “”Learn how to build the Kubernetes app you’ve always wanted with EKS and @CodeShip””]
Watch the webinar on managing CI/CD in the cloud
Read about using CodeShip to automate Cloudflare Worker deployments
Learn how CloudBees CodeShip can help you deploy Docker apps to Kubernetes