I'm running my application in AWS-EKS and my Jenkins instance is not yet containerized. To deploy our application we are using kubectl command in the Jenkins Pipeline. I'm wondering any best practice or plugin for Kubernetes deployment via Jenkins.
So far I found below plugins which do not completely work with my use-case.
https://github.com/jenkinsci/kubernetes-plugin - To run dynamic Jenkins agents. May not be suitable for my case.
https://github.com/jenkinsci/kubernetes-cd-plugin - This plugin is providing the K8s Deployment functionality, but interacting with EKS is a bit of concern with this plugin as in EKS authentication is done by aws-iam-authenticator
Is there any plugin available in Jenkins to handle Kubernetes deployment?
Any pointers would be helpful.
Note : This question was already asked couple of years ago, but did not get any proper answers. So just wanted to repost.
According to this issue the second plugin you've mentioned is not compatible with aws-iam-authenticator and efforts to do so have not been met with response from maintainers.
The first plugin will probably require to use the same kubectl flow you are using today, and will only simplify authenticating to your clusters, so I agree it's not the best fit to what you are trying to do.
I haven't used this tool myself, but from what I hear the most common tool for deploying code to kubernetes with Jenkins should be JenkinsX, I would look into that if I were you.
Related
The Jenkins landscape is vast and new progress is difficult to keep track especially if you are not a regular DevOps.
I am currently in process of setting up a Jenkins CI system from scratch. I am looking for the best possible ways to get the Jenkins instance up and running. I have looked at options such as running from the JAR, setting it up a service, docker, blue ocean, etc.
I was wondering if you can please share your experience if there is a pre-configured setup or a scalable Jenkins solution already available in the market which is ready to be configured/deployed.
One of the key tenant on this Jenkins instance would be test automation guys running their Selenium tests (or I am ideally looking at Windows server installation although CentOS is an option) and would like to make it working for them as easy as possible.
I'm a Jenkins admin. In my company I've set up Jenkins on our Kubernetes cluster using the Helm chart with a custom docker image preloaded with plugins (you don't want to rely on the plugin update site during startup). All configuration is done with the Configuration as Code Plugin. We're using the Kubernetes plugin to do horizontally scaling. No builds are allowed on the build controller, everything is done within agents, which is custom docker images inspired by these images. and we don't allow no builds to run on the build controller. This works very well, and I'm very happy with the setup. There is also a Jenkins Kubernetes Operator which looks promising, but I havent tried it myself.
If you're not on Kubernetes, you can take a look at the Jenkins Evergreen project.
PS: The Blue Ocean project is dead, but the folks over at Cloudbees are currently in the process of overhauling the UX. They just released a weekly version where they got rid of all tables so the design is slowly becoming more and more responsive, and also a new set of icons is also coming up.
Maybe the nearest you can get to a pre-configurated Jenkins Instance is using the Docker Image (https://hub.docker.com/r/jenkins/jenkins). But also with the docker image, you have to selected plugins and so on. Maybe you want to raise an issue as purposal in the Jenkins Docker repository to make it possible to pre-configure Jenkins (Github Repo: https://github.com/jenkinsci/docker/issues)?
We are developing a CI/CD pipeline leveraging Docker/Kubernetes in AWS. This topic is touched in Kubernetes CI/CD pipeline.
We want to create (and destroy) a new environment for each SCM branch, since a Git pull request until merge.
We will have a Kubernetes cluster available for that.
During prototyping by the dev team, we came up to Kubernetes namespaces. It looks quite suitable: For each branch, we create a namespace ns-<issue-id>.
But that idea was dismissed by dev-ops prototyper, without much explanation, just stating that "we are not doing that because it's complicated due to RBAC". And it's quite hard to get some detailed reasons.
However, for the CI/CD purposes, we need no RBAC - all can run with unlimited privileges and no quotas, we just need a separated network for each environment.
Is using namespaces for such purposes a good idea? I am still not sure after reading Kubernetes docs on namespaces.
If not, is there a better way? Ideally, we would like to avoid using Helm as it a level of complexity we probably don't need.
We're working on an open source project called Jenkins X which is a proposed sub project of the Jenkins foundation aimed at automating CI/CD on Kubernetes using Jenkins and GitOps for promotion.
When you submit a Pull Request we automatically create a Preview Environment which is exactly what you describe - a temporary environment which is used to deploy the pull request for validation, testing & approval before the pull request is approved.
We now use Preview Environments all the time for many reasons and are big fans of them! Each Preview Environment is in a separate namespace so you get all the usual RBAC features from Kubernetes with them.
If you're interested here's a demo of how to automate CI/CD with multiple environments on Kubernetes using GitOps for promotion between environments and Preview Environments on Pull Requests - using Spring Boot and nodejs apps (but we support many languages + frameworks).
I'm using Jenkins for Continuous Integration tool with DevOps tools like JIRA, Confluence, Crowd, SonarQube, Hygieia, etc.
But the environments are changed to deploy microservices to PaaS.
So I got the issues to resolve below.
Deployment Monitoring
to view which application is deployed to what instance with which version.
Canary Deployment
deploy to 1 instance and then deploy to all instances(after manual approval or auto).
Deploy to Cloud Foundry
more specifically IBM Bluemix
So I examined Spinnaker but I found that the cloud driver for CF is no longer maintained.
https://github.com/spinnaker/clouddriver/pull/1749
Do you know another open-sourced CD tool?
take a look at concourse : https://concourse-ci.org/
Its open source, you can us it to deploy either application or cloud foundry. It's a central tool for DevOps. Basically you have pipelines that can trigger tasks (manually or automatically). You have some already created ressources (github connector, etc ...) but you can also create your own tasks. Its running docker containers as workers to execute tasks/jobs.
Best,
I find it relatively easy to integrate a CD server to any PaaS provider. You will have to either use a plugin or create your own integration.
My top two recommendations would be gitlab or Bamboo in that order.
Given your preference for Jira, you might prefer Bamboo as it has very good integration with the rest of that Atlassian tools but it is not open source.
I feel it's a little crazy I couldn't find anything along these lines, especially as it's an incredibly simple requirement: Is there a way you can deploy from Jenkins using SSH/SCP, yet write only one instance of a transfer-set/exec script?
As it stands, deploying to servers is kind of INSANE in that I need to create a new "Deploy to SSH" task, choose a different server from the drop down and then copy/past all transfer-sets and execs from the previous entry. Then do it again. And again. And again.
There must be a better way?
This may not be a short-term immediate solution for your question---
(On long run this can be used)
Your requirement seems to me like you need a configuration management equipment. You could use Chef, Puppet or Ansible. And automation of this deployment can be done using Jenkins CI.
One example of how to deploy an application on jboss using Ansible -
Deploy a hello world application
jboss: src=/tmp/hello-1.0-SNAPSHOT.war deployment=hello.war state=present
Of course, this will require installation of Ansible and little bit of initial configuration. Ansible is simplest of all deployment mechanisms.
Check this for more details - http://docs.ansible.com/ansible/intro.html
I want to use Amazon EC2 plugin for setting up autoscaled Slaves.
We aim to script everything using Chef and so far I haven't found anything for this Jenkins plugin. I want to write a cookbook of my own but am wondering what is the best way to do it?
Generally management of the build machine would be done through the EC2 plugin itself, it already installs the Jenkins remote jar for you, so all you need to do beyond that is make sure Java is installed.
There are two methods to use Amazon EC2 plugin and Chef together:
Run Chef to do provisioning on each slave launch or build start
Build pre-baked slave images using Chef and something like Packer and provide them to Jenkins Amazon EC2 plugin
Cons of the first approach:
May take a lot of time depending on what software you are installing with Chef. So it would give a latency for build start and extra bill for machine time.
You can't always get the same build environment you have last time. May lead to heisenbugs and hard troubleshooting.
The second approach is known as Immutable Server. It has its cons too:
Gives you an extra bill for AMI storage.
Less flexible — you can't just fix some version numbers or add requirements for some new software and start a new Jenkins build. You have to rebuild your slave images first. And if you need even slightly different environments you have to build and keep several pre-baked images.
I myself use the second approach right now. You could check source code here. Specifically, configuration of Amazon EC2 plugin with Chef is done here.