11 ms·

Jenkins X: a CI/CD solution for cloud applications on Kubernetes

245 points by Garbage 8y ago

nodesocket 8y ago
No TLS on jenkins-x.com, tisk tisk.
- tuananh 8y ago
  it's using github pages for the main website i think so i'm not sure if it's possible to setup custom domain + custom ssl cert for it?
  - jsmeaton 8y ago
    I've used cloudflare to do SSL for a custom github pages domain before.
  - nodesocket 8y ago
    Should be able to use CloudFlare and "flexible" SSL setup. CNAME at the apex pointing to GitHub pages.
    - manigandham 8y ago
      You should set it to "Full" instead. That will use TLS but won't verify the domain name in the certificate like it does in "Strict" mode so you can still use Github pages.
    - LethargicStud 8y ago
      Please don't do this. It gives the user the illusion that their connection is secure, but the connection between Cloudflare and the site is not secure. Arguably it's better to encrypt some of the route rather than none of it, but also giving people a false sense of security comes with its own drawbacks.
      - nodesocket 8y ago
        Actually "flexible" might not be needed, "full" without strict should work. Traffic is still over TLS, but a valid named certificate is not required.
      - deleted 8y ago
        [deleted]
      - jhasse 8y ago
        I think the user mostly cares about his connection to anything outside his network (e.g. for public WiFis).
  - samridh90 8y ago
    It's possible but not very straightforward. Reference for anyone else trying to setup ssl cert for github pages: https://www.jonathan-petitcolas.com/2017/01/13/using-https-with-custom-domain-name-on-github-pages.html https://www.jonathan-petitcolas.com/2017/01/13/using-https-w...
  - EnderMB 8y ago
    For a long time it wasn't, but it looks like GitHub are slowly rolling this out to people. Given that Jenkins is pretty popular, you'd think that they'd be able to sort something out with GitHub to get bumped up the list for something along these lines. There's always the Cloudfare option, but I've never felt that this was an ideal solution when HTTPS should be extremely straightforward for GitHub to set up on their pages.
- spockz 8y ago
  I’m using netlify[1] to host my site and it supports tls on public domains - through let’s encrypt - and http2 out of the box. [1]: https://www.netlify.com/ https://www.netlify.com/
- pronoiac 8y ago
  Huh, they're using Github pages. I thought if you set up a redirect - a C dns response - to whatever.github.io, that would soothe the ssl complaints in the browser. Looking at the dns records, it looks like they didn't do this, and instead set up an A record. I realized Github probably documents this, and found: https://help.github.com/articles/using-a-custom-domain-with-github-pages/ https://help.github.com/articles/using-a-custom-domain-with-... My suggestion would likely work for a www subdomain, but not for the apex domain.
- jstrachan 8y ago
  whoops, great catch thanks. Hoping we can figure out a fix very soon...
ku6pk 8y ago
In no attempt to bash OP at all, but what is the HN policy on links that have been posted before? Edit: Previous posts for reference https://news.ycombinator.com/item?id=16622215 https://news.ycombinator.com/item?id=16622215 https://news.ycombinator.com/item?id=16626765 https://news.ycombinator.com/item?id=16626765 https://news.ycombinator.com/item?id=16628313 https://news.ycombinator.com/item?id=16628313 https://news.ycombinator.com/item?id=16658640 https://news.ycombinator.com/item?id=16658640
- tomhoward 8y ago
  It's only considered a dupe if the story/topic/product release has had significant attention (front page presence and discussion) in the past 12 months. None of these posts got much attention. See dang's comments on the issue for the official position: https://hn.algolia.com/?query=dang%20dupe%20porous&sort=byPopularity&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=dang%20dupe%20porous&sort=byPo...
  - ku6pk 8y ago
    Thanks for the informative post and link.
    - tomhoward 8y ago
      No worries! By the way, it's frowned upon if one person posts the same link repeatedly without getting any traction - eventually it just gets annoying, especially for people who watch the 'new' feed and keep seeing the same thing coming up. But the above posts seem to be submitted by different people, so it's all good.
fredsted 8y ago
So we already have a very custom Jenkins setup that builds containers, runs tests and creates test environments out of our pull requests in a k8s namespace. This seems to come with so many things that we already have. We have a few issues with it, like Jenkins suddenly deciding to build & test all branches/PRs in all repos, killing the server. • What is Jenkins X exactly, and how does it relate to Jenkins? Is it just a CLI utility that generates git repos, k8s clusters and Jenkinsfiles for us? Is it a fork of Jenkins? • What would we gain from switching to Jenkins X? • How does it work with our existing setup?
- vasco 8y ago
  > We have a few issues with it, like Jenkins suddenly deciding to build & test all branches/PRs in all repos, killing the server. I suspect you're using the "organization folder" plugin-thing that periodically re-scans your origin (Github/Bitbucket) and builds all branches that it discovers. Check this out: https://stackoverflow.com/questions/45832235/how-to-restrict-automatic-build-trigger-after-the-organization-scan-in-jenkins https://stackoverflow.com/questions/45832235/how-to-restrict...
- ec109685 8y ago
  He answers this to some extent here: > Relationship between Jenkins and Jenkins X Jenkins is the core CI/CD engine within Jenkins X. So Jenkins X is built on the massive shoulders of Jenkins and its awesome community. > We are proposing Jenkins X as a sub project within the Jenkins foundation as Jenkins X has a different focus: automating CI/CD for the cloud using Jenkins plus other open source tools like Kubernetes, Helm, Git, Nexus/Artifactory etc. > Over time we are hoping Jenkins X can help drive some changes in Jenkins itself to become more cloud native, which will benefit the wider Jenkins community in addition to Jenkins X.
- jstrachan 8y ago
  The things you gain from switching to Jenkins X: * automated CI/CD for your kubernetes based applications using Helm Charts & GitOps to manage promotions (manual or automated) * a single command to create a kubernetes cluster, install Jenkins X and all the associated software all configured for you OOTB (including Jenkins, Nexus, Monocular etc): http://jenkins-x.io/getting-started/create-cluster/ http://jenkins-x.io/getting-started/create-cluster/ - ditto for upgrading * a single command to create new apps or import them via build packs to create docker images, pipelines and helm charts with GitOps promotion: http://jenkins-x.io/developing/create-spring/ http://jenkins-x.io/developing/create-spring/ * automated release notes + change logs with links to github/JIRA issues etc * feedback on issues as they move from Staging -> Production i.e. more automation around CI/CD and kubernetes so you can spend more time focussing on building your apps and less time installing/configuring/managing Jenkins + Pipelines
zippie 8y ago
I find this solution compared to the gitlab Auto Devops, frankly, underwhelming. We recently deployed AD in our self hosted gitlab instance and combined the SAST container checks with our production policies, it’s been rock solid. Add to this the fact we are able to manage all the production policies via the pipeline API’s and AD templates, the whole Jenkinsfiles deal seems far less scalable and difficult. I have no affiliation with gitlab.
- jstrachan 8y ago
  Sorry to hear you're underwhelmed! Did you check out the GitOps features for versioning all changes to all Environments in git with human approval? http://jenkins-x.io/about/features/#promotion http://jenkins-x.io/about/features/#promotion Or the automated feedback on releases to all your issues as they move through Environments: http://jenkins-x.io/about/features/#feedback http://jenkins-x.io/about/features/#feedback Or the automatic publishing of Helm charts to the bundled Monocular for all versions of your apps for your colleagues to easily be able to run via helm? Or that it works great with GitHub, GitHub Enterprise & JIRA and has awesome integration with Skaffold? Or easy setup a kubernetes cluster with Jenkins X on any public cloud in one command: http://jenkins-x.io/getting-started/create-cluster/ http://jenkins-x.io/getting-started/create-cluster/
  - deleted 8y ago
    [deleted]
- sytse 8y ago
  Thanks for using GitLab. If people want to see some raw footage of me using Auto DevOps with Spring after linking it to a Kubernetes cluster please see https://www.youtube.com/watch?v=9D5TwMo-IIw https://www.youtube.com/watch?v=9D5TwMo-IIw We're considering renaming Auto DevOps to GitOps. What do people think?
  - kronin 8y ago
    Please don't. I am using gitlab, though we quickly grew beyond auto devops. Your definition of auto devops is different than gitops. Gitops is the practice of using commits and pull requests to execute change and do releases. Weave uses it to mean git as the source of truth. https://www.weave.works/blog/gitops-operations-by-pull-request https://www.weave.works/blog/gitops-operations-by-pull-reque... Kelsey Hightower talked about it and and has demoed the workflow of using pull requests to initiate promotion and deployments. Gitlab's auto devops does not seem to tackle promotion via environment repos, so in my understanding does not fit gitops and would be confusing to call it such. Edit: Kelsey Hightower's kubeconf talk - https://www.youtube.com/watch?v=07jq-5VbBVQ https://www.youtube.com/watch?v=07jq-5VbBVQ And a better writeup on weave's site -https://www.weave.works/blog/gitops-high-velocity-cicd-for-kubernetes https://www.weave.works/blog/gitops-high-velocity-cicd-for-k...
kosta_self 8y ago
Does anyone have Jenkins in production and found it to be reliable and pleasant to use? I had to do lots of Jenkins integrations some time ago, and even though I tried to minimize the number of plugins and make things as simple as possible, things would randomly break from time to time or exhibit weird behaviour etc. I had the impression that Jenkins is deeply conceptually confused about some of its concepts, e.g. how builds are triggered. Also, it is a huge pile of untestable spaghetti code which explains the weird bugs. I modified an open-source plugin only to find out that it's almost impossible to write meaningful tests for it: you can't even mock Jenkins API without using the darkest Java mock magic. Jenkins classes are just written in an old style that makes testing _really_ hard but probably can't be changed without breaking all of Jenkins. I tried Jenkinsfile which was only even more unreliable (at the time at least, this was > 1y ago). The whole idea of using groovy, modifying the hell out of it to make it even more weird and surprising and edge-casy just didn't go well for me. I ended up with generating a _lot_ of very simple jobs for each project and connecting them via triggers instead. It was not very pretty, but it was the most reliable that I could get out of Jenkins. So the thought of integrating Jenkins deeply into you deployments, talking to Kubernetes and sitting in the middle of a huge pile of complexity (Jenkinsfile, Dockerfile, Helm, ...) and magic "that you don't need to worry about" scares the hell out of me. But then again, if you want to do CI/CD with Jenkins that's what you might want, right? (I would prefer more simple approaches if forced to use Jenkins, though)
- abrookewood 8y ago
  We use it in all of our environments and it is extremely flexible, mostly reliable, but still feels like a hodgepodge of plugins and various components. Once you throw in a variety of build tools and deployment options etc, it can get rather unwieldy. Still, we use it for almost everything now (no forgotten cron jobs running on random servers) and it gets the job done. I often think we should investigate other options, but we have made such an investment at this point it would be a massive undertaking to move to something else.
- sammm 8y ago
  I actually think Jenkins is way too flexible for most use cases. We moved to GitLab CI which isn't perfect, but it provides safety rails/structure/opinions that pretty much provides an answer for everything you want to do, apart from maybe obscure corner cases that might not make sense for a CI/CD tool anyways. Also you get the close integration of your CI tool and your git repos, which is very nice from a visibility point of view. Having said that, GitLab is trying to own all parts of the build and deployment process, which from previous HN discussions, is of great annoyance to a lot of people who want to cherry pick what they use GitLab for.
tirumaraiselvan 8y ago
If I understand correctly, this creates an environment for each PR. How does it accomplish that exactly? It would require all Kubernetes manifests for resources somewhere in the repo? What if the environment has some stateful dependencies, etc?
- jstrachan 8y ago
  Jenkins X creates a Preview Environment per Pull Request yeah; which can be as much or as little as you want it to be. e.g. it could be just 1 pod only or could be a suit of related apps (you may want to test multiple things together). You can define what a Preview Environment is in the source code of your application - its just a different Helm chart really. You can of course opt out of Preview Environments completely if you wish. http://jenkins-x.io/about/features/#preview-environments http://jenkins-x.io/about/features/#preview-environments Though I've personally found them to be super useful - especially if you are working on web consoles - it lets you try out changes visually as part of the Pull Request review process before you merge to master.
- jstrachan 8y ago
  BTW we're hoping to make it easier to 'service link' your Preview Environments to other environments. https://github.com/jenkins-x/jx/issues/573 https://github.com/jenkins-x/jx/issues/573 e.g. so you could deploy just your front end in a Preview Environment but link it to all the back end services running in the Staging or Production environment. Each team can configure their Preview environment helm chart however they wish really. Using separate namespaces in kubernetes is a great way to keep software isolated and avoids apps interfering with each other; but at the same time its really handy to be able to link services between namespaces too.
dankohn1 8y ago
Lots of innovation occurring in the CI/CD space around Kubernetes. We just added JenkinsX to the cloud native interactive landscape: https://landscape.cncf.io/grouping=landscape&landscape=ci-cd&selected=jenkins-x https://landscape.cncf.io/grouping=landscape&landscape=ci-cd...
adam-_- 8y ago
Presumedly this is only of interest for those running Kubernetes?
- jstrachan 8y ago
  Btw I’m the author of the above blog post & committer on Jenkins X. So our focus is currently anyone looking to automate CI/CD on kubernetes, the cloud or any modern platform like OpenShift, Mesos or CloudFoundry which all come with kubernetes support baked in. You can use just the CI part and do CI & releasing of non-cloud native apps if you want - we use Jenkins X to release jars, plugins & docker images using it - but doing so does miss out all the benefits of automated Continuous Delivery & GitOps promotion across environments
mekazu 8y ago
Just remember the name XKCD is already taken.
cfontes 8y ago
This looks like an improvement over what Jenkins 2.0 provides and I wish you guys good luck. I have used and vouched for Jenkins in several companies and some decent sized licenses were bought mainly because of my input. But to me, Cloudbees has done a major dick move making the stages not restartable in Jenkins 2.0, among other things. E.g: Dropping stage view out of nowhere and focusing only in Blue Ocean. I complained about in the channels that I had at the time and the response was, it's going to be unsupported from now on. It's a super squechy thing to have such a useful feature bundled with a bunch of support and useless stuff that I don't care, and then charge me per node. I am migrating away from Jenkins into GoCD after close to 10 years using it, and don't get me wrong I don't feel happy doing this, but it's hard to justify it. Fortunately the future looks bright, there are several interesting solutions available, Argo is super interesting to me, looking forward for Argo CD!
- oblio 8y ago
  They've changed their mind because of the community backlash: https://issues.jenkins-ci.org/browse/JENKINS-45455 https://issues.jenkins-ci.org/browse/JENKINS-45455
  - cfontes 8y ago
    Thank you I did not know about that. Last time I checked with the sales guy it was not going to happen. I hope they improve their ways, it's a nice tool and I invested a lot of my time into it, but right now GoCD is my default option from now on.
    - moritzplassnig 8y ago
      If you have more feedback, I'm happy to connect with one of the PMs or somebody from the Jenkins OSS team. I'm the founder/CEO of Codeship and we got acquired by CloudBees earlier this year. And I want to make sure that Jenkins + all CloudBees products get better :)
      - cfontes 8y ago
jillesvangurp 8y ago
This solves part of a real problem. There are a lot of tools out there but end to end integration is left as an exercise to the reader. I'd love some out of the box sanity when it comes to devops, CI/CD, and cloudhosting. Instead I'm stuck building nw architectures, deployment scripting, dealing with archaic broken by default configs of misc bits and pieces, host configurations, build servers & CI/CD pipelines, etc. from scratch. Add log aggregation, security auditing, and other nice to haves that are actually not optional these days (what are you running blind and ignoring failed ssh attempts?) and you have a full explanation why so many companies make a mess of all of the above. IMHO a lot of stuff in this space are either focusing on making life harder through added complexity to up-sell support or more services or on solving a narrow problem in such a way that you have to still take care of a lot of other stuff.
C4stor 8y ago
Interesting annoucement, I'd like it better if there was a clear comparison between the current possibilities offered by Jenkins 2.0 and this version of Jenkins. I'm not huge fan of the demo video, since it doesn't really handle what I can only imagine is a very common use case : I already have a Jenkins 2.0 instance with Jenkinsfiles, how easy would it be to migrate to Jenkins X ? Is it isofunctional with added capabilities ? How much will I lose ? Bootstrapping a java spring app from scratch is fun, but I suspect most people have an already existing codebase with already existing CI/CD tools.
- jstrachan 8y ago
  That’s a great point. This blog tries to compare Jenkins X versus Jenkins 2.0: https://dzone.com/articles/jenkins-x-the-good-bad-and-ugly https://dzone.com/articles/jenkins-x-the-good-bad-and-ugly It’s mostly about automation of install, configuration, environments, pipelines & promotion with GitOps and more feedback. Just out of interest what kind of demo would you like to see?
- tootie 8y ago
  I'm leery of projects whose goal is make bootstrapping easier. Bootstrapping projects has generally gotten easier and easier and was never a real bottleneck. Projects spend 99% of their lifetime in development and maintenance so those are the parts that need the most help.
jdc0589 8y ago
Looks pretty cool. I really don't like the idea of my ci/cd tooling being responsible for provisioning its own k8s cluster....there are a lot of other more mature projects out there for doing this. Is the idea that the ONLY thing running on this cluster is jenkins-x and review/preview environments or something?
- jstrachan 8y ago
  Thanks! You are free to use any kubernetes cluster and install Jenkins X there: http://jenkins-x.io/getting-started/install-on-cluster/ http://jenkins-x.io/getting-started/install-on-cluster/ The default is to use separate namespaces in kubernetes for each teams developer tools & pipelines, Staging & Production environments (plus Preview Environments). Multiple teams can obviously use the same cluster with different namespaces. We’d expect ultimately folks may want to use a separate cluster for development & testing to Production. GitOps makes that kind of decoupling pretty easy but we’ve still work to do to automate easily setting up a multi-cluster approach: https://github.com/jenkins-x/jx/issues/479 https://github.com/jenkins-x/jx/issues/479
amq 8y ago
When I started using Travis I immediately got a fan of it. Not having worked with Jenkins before, when I first tried it (pre-blue ocean), I was shocked by the unnecessary complexity. Since then, I've settled with a self-hosted drone.io for private projects, it offers a very similar experience to Travis, while I don't feel like I'm lacking anything compared to Jenkins.
- greenhatman 8y ago
  Is the self-hosted version the same as the hosted enterprise version? Or are there features missing? Is it easy to self-host?
djabatt 8y ago
Automation is never easy. If you zoom your focus out watching the innovation in the ci/cd space is fascinating. Not to sound like an old fart but doing this all by hand back in the day sucked. Jenkins for us has made a lot easier. Curious to try GitLab and Jenkins X on a new projects
theptip 8y ago
Looks interesting, * I use one namespace per env (staging, prod, etc), is this supported or must I go with the default (slightly wacky) staging and prod releases side-by-side in the same namespace? * How are bugfix releases handled? If I pushed 1.2.0 to staging, and want to hotfix the prod release 1.1.0 with 1.1.1 (a common bugfix flow), can I promote releases from the hotfix branch? * Is there a permission model? Does it bottom out to GitHub permissions for each env repository? E.g. can I have a smaller set of users approved to promote releases to production?
- jstrachan 8y ago
  Each environment is in a separate namespaces. You can add/edit/delete the Environments to use whatever namespaces you wish to use. Promotion is either automatic or manual. By default Staging is automatic and production is manual. You can manually promote any version to any environment whenever you wish: http://jenkins-x.io/developing/promote/ http://jenkins-x.io/developing/promote/ For promotions we're delegating to the git repository for RBAC; so you can setup whatever roles you want for who is allowed to approve promotions & if you need code reviews etc
dcosson 8y ago
It's not completely clear to me from reading the site - does this run a non-dockerized app build in kubernetes, or does it also work for building and deploying my app as a docker container itself? This usually requires things like being able to spin up a cluster of containers per build - one with my app, one with a database to run against, maybe one with memcached or elasticsearch for integration tests, etc. And does it work out of the box for complicated cases like partitioning a large test suite to run in parallel, where each parallel part of the build needs its own mini cluster of a couple of containers talking to each other? I haven't looked into the current state of this recently but I ran into a lot of problems with this with a bunch of hosted CI services in the past. Somewhat ironically, as of a couple years ago if you needed to build your own docker container as part of a build you had to specifically stay clear of CI services that mentioned docker at all because that meant they were running their builds inside of containers and it was a pain to figure out how to run my own docker build, much less spin up a cluster per build with something like docker-compose, inside of a running container. Curious if and how Jenkins X solves this. Or have things changed and it's now easy to build and run docker containers inside of a container? (Aside from that, I'm not sure how I feel about Jenkins coordinating with a Kubernetes cluster. I've always found their monolithic approach to be a pain to work with, and always wished that, for example, I could just have Jenkins trigger jobs by pushing them onto an ActiveMQ queue or something and read back the results on another queue. Then I could just set up an autoscaling group of build servers, and provision them with whatever tools I'm already using to just start up and listen on this queue. Instead, jenkins wants me to duplicate a lot of this work I already have CM tools doing, and set it up manually through the UI, using community plugins that are often out of date).
- kohsuke 8y ago
  I defer the question about container building in Kubernetes to somebody from the Jenkins X team, but I wanted to respond to your side note. Offloading build queue outside Jenkins to another service, auto-scaling of build servers, configuring Jenkins with your configuration management tools are all something we are thinking about / looking into / actively working on. Some of them haven't gotten to the point of proper write-up yet, but see - https://github.com/jenkinsci/jep/tree/master/jep/201 https://github.com/jenkinsci/jep/tree/master/jep/201 - https://github.com/jenkinsci/configuration-as-code-plugin https://github.com/jenkinsci/configuration-as-code-plugin - https://github.com/kohsuke/jenkinsfile-runner https://github.com/kohsuke/jenkinsfile-runner
tra3 8y ago
I can't find this in the docs; but what happens when a promotion fails? Do things get rolled back to previous known state? The reason I ask is because I"m trying to replicate similar functionality in our much simpler environment.
- jstrachan 8y ago
  we're using helm for installing/upgrading apps; it takes care of reverting bad versions/releases etc
  - tra3 8y ago
    Thanks, that's helpful, but we're not mature enough for k8s yet. What else can I look at?
    - jstrachan 8y ago
      if you can't use kubernetes or containers then I guess Ansible is a fallback?
tlynchpin 8y ago
Is it appropriate to compare this with OpenShift, and if so then what are the highlights of this comparison? I use Jenkins and k8s and the objective is generally Spring services, so it sounds like this is for me.
- jstrachan 8y ago
  OpenShift is Red Hat's supported fork & distribution of Kubernetes - so its another platform we can install and use Jenkins X on. OpenShift also includes some Jenkins support; e.g. you can add BuildConfig resources via a YAML file in the OpenShift CLI which will create a Jenkins server and a pipeline. But Jenkins X isn't yet integrated into OpenShift - but its easy to add yourself for now :) If you are pondering which kubernetes cluster to try for developing Spring services: OpenShift is a good option if you are on premise. If you can use the public cloud then GKE on Google is super easy to use; AKS on Azure is getting there & EKS is looking like it will be good if you use AWS. On the public clouds the managed kubernetes services are looking effectively free; you just pay for your compute + storage etc. So its hard to argue with free + managed + easy to use kubernetes - if you are allowed to use the public cloud!
  - dankohn1 8y ago
    OpenShift is Certified Kubernetes, so not a fork. See: cncf.io/ck (Disclosure: I run the Certified Kubernetes program at CNCF.)
    - jstrachan 8y ago
      OpenShift is a fork of the Kubernetes code base: https://github.com/openshift/origin https://github.com/openshift/origin I.e. it’s not using the upstream distribution of Kubernetes like the public cloud vendors or Heptio etc. It’s great it’s a Certified Kubernetes though!
      - dankohn1 8y ago
        Fork has a perjorative meaning, as in taking it and going their own direction. I would describe OpenShift as a distribution.

245 points by Garbage 8y ago

nodesocket 8y ago

No TLS on jenkins-x.com, tisk tisk.

tuananh 8y ago
it's using github pages for the main website i think so i'm not sure if it's possible to setup custom domain + custom ssl cert for it?
- jsmeaton 8y ago
  I've used cloudflare to do SSL for a custom github pages domain before.
- nodesocket 8y ago
  Should be able to use CloudFlare and "flexible" SSL setup. CNAME at the apex pointing to GitHub pages.
  - manigandham 8y ago
    You should set it to "Full" instead. That will use TLS but won't verify the domain name in the certificate like it does in "Strict" mode so you can still use Github pages.
  - LethargicStud 8y ago
    Please don't do this. It gives the user the illusion that their connection is secure, but the connection between Cloudflare and the site is not secure. Arguably it's better to encrypt some of the route rather than none of it, but also giving people a false sense of security comes with its own drawbacks.
    - nodesocket 8y ago
      Actually "flexible" might not be needed, "full" without strict should work. Traffic is still over TLS, but a valid named certificate is not required.
    - deleted 8y ago
      [deleted]
    - jhasse 8y ago
      I think the user mostly cares about his connection to anything outside his network (e.g. for public WiFis).
- samridh90 8y ago
  It's possible but not very straightforward. Reference for anyone else trying to setup ssl cert for github pages: https://www.jonathan-petitcolas.com/2017/01/13/using-https-with-custom-domain-name-on-github-pages.html https://www.jonathan-petitcolas.com/2017/01/13/using-https-w...
- EnderMB 8y ago
  For a long time it wasn't, but it looks like GitHub are slowly rolling this out to people. Given that Jenkins is pretty popular, you'd think that they'd be able to sort something out with GitHub to get bumped up the list for something along these lines. There's always the Cloudfare option, but I've never felt that this was an ideal solution when HTTPS should be extremely straightforward for GitHub to set up on their pages.
spockz 8y ago
I’m using netlify[1] to host my site and it supports tls on public domains - through let’s encrypt - and http2 out of the box. [1]: https://www.netlify.com/ https://www.netlify.com/
pronoiac 8y ago
Huh, they're using Github pages. I thought if you set up a redirect - a C dns response - to whatever.github.io, that would soothe the ssl complaints in the browser. Looking at the dns records, it looks like they didn't do this, and instead set up an A record. I realized Github probably documents this, and found: https://help.github.com/articles/using-a-custom-domain-with-github-pages/ https://help.github.com/articles/using-a-custom-domain-with-... My suggestion would likely work for a www subdomain, but not for the apex domain.
jstrachan 8y ago
whoops, great catch thanks. Hoping we can figure out a fix very soon...

ku6pk 8y ago

In no attempt to bash OP at all, but what is the HN policy on links that have been posted before? Edit: Previous posts for reference https://news.ycombinator.com/item?id=16622215 https://news.ycombinator.com/item?id=16622215 https://news.ycombinator.com/item?id=16626765 https://news.ycombinator.com/item?id=16626765 https://news.ycombinator.com/item?id=16628313 https://news.ycombinator.com/item?id=16628313 https://news.ycombinator.com/item?id=16658640 https://news.ycombinator.com/item?id=16658640

tomhoward 8y ago
It's only considered a dupe if the story/topic/product release has had significant attention (front page presence and discussion) in the past 12 months. None of these posts got much attention. See dang's comments on the issue for the official position: https://hn.algolia.com/?query=dang%20dupe%20porous&sort=byPopularity&prefix&page=0&dateRange=all&type=comment https://hn.algolia.com/?query=dang%20dupe%20porous&sort=byPo...
- ku6pk 8y ago
  Thanks for the informative post and link.
  - tomhoward 8y ago
    No worries! By the way, it's frowned upon if one person posts the same link repeatedly without getting any traction - eventually it just gets annoying, especially for people who watch the 'new' feed and keep seeing the same thing coming up. But the above posts seem to be submitted by different people, so it's all good.

fredsted 8y ago

So we already have a very custom Jenkins setup that builds containers, runs tests and creates test environments out of our pull requests in a k8s namespace. This seems to come with so many things that we already have. We have a few issues with it, like Jenkins suddenly deciding to build & test all branches/PRs in all repos, killing the server. • What is Jenkins X exactly, and how does it relate to Jenkins? Is it just a CLI utility that generates git repos, k8s clusters and Jenkinsfiles for us? Is it a fork of Jenkins? • What would we gain from switching to Jenkins X? • How does it work with our existing setup?

vasco 8y ago
> We have a few issues with it, like Jenkins suddenly deciding to build & test all branches/PRs in all repos, killing the server. I suspect you're using the "organization folder" plugin-thing that periodically re-scans your origin (Github/Bitbucket) and builds all branches that it discovers. Check this out: https://stackoverflow.com/questions/45832235/how-to-restrict-automatic-build-trigger-after-the-organization-scan-in-jenkins https://stackoverflow.com/questions/45832235/how-to-restrict...
ec109685 8y ago
He answers this to some extent here: > Relationship between Jenkins and Jenkins X Jenkins is the core CI/CD engine within Jenkins X. So Jenkins X is built on the massive shoulders of Jenkins and its awesome community. > We are proposing Jenkins X as a sub project within the Jenkins foundation as Jenkins X has a different focus: automating CI/CD for the cloud using Jenkins plus other open source tools like Kubernetes, Helm, Git, Nexus/Artifactory etc. > Over time we are hoping Jenkins X can help drive some changes in Jenkins itself to become more cloud native, which will benefit the wider Jenkins community in addition to Jenkins X.
jstrachan 8y ago
The things you gain from switching to Jenkins X: * automated CI/CD for your kubernetes based applications using Helm Charts & GitOps to manage promotions (manual or automated) * a single command to create a kubernetes cluster, install Jenkins X and all the associated software all configured for you OOTB (including Jenkins, Nexus, Monocular etc): http://jenkins-x.io/getting-started/create-cluster/ http://jenkins-x.io/getting-started/create-cluster/ - ditto for upgrading * a single command to create new apps or import them via build packs to create docker images, pipelines and helm charts with GitOps promotion: http://jenkins-x.io/developing/create-spring/ http://jenkins-x.io/developing/create-spring/ * automated release notes + change logs with links to github/JIRA issues etc * feedback on issues as they move from Staging -> Production i.e. more automation around CI/CD and kubernetes so you can spend more time focussing on building your apps and less time installing/configuring/managing Jenkins + Pipelines

zippie 8y ago

I find this solution compared to the gitlab Auto Devops, frankly, underwhelming. We recently deployed AD in our self hosted gitlab instance and combined the SAST container checks with our production policies, it’s been rock solid. Add to this the fact we are able to manage all the production policies via the pipeline API’s and AD templates, the whole Jenkinsfiles deal seems far less scalable and difficult. I have no affiliation with gitlab.

jstrachan 8y ago
Sorry to hear you're underwhelmed! Did you check out the GitOps features for versioning all changes to all Environments in git with human approval? http://jenkins-x.io/about/features/#promotion http://jenkins-x.io/about/features/#promotion Or the automated feedback on releases to all your issues as they move through Environments: http://jenkins-x.io/about/features/#feedback http://jenkins-x.io/about/features/#feedback Or the automatic publishing of Helm charts to the bundled Monocular for all versions of your apps for your colleagues to easily be able to run via helm? Or that it works great with GitHub, GitHub Enterprise & JIRA and has awesome integration with Skaffold? Or easy setup a kubernetes cluster with Jenkins X on any public cloud in one command: http://jenkins-x.io/getting-started/create-cluster/ http://jenkins-x.io/getting-started/create-cluster/
- deleted 8y ago
  [deleted]
sytse 8y ago
Thanks for using GitLab. If people want to see some raw footage of me using Auto DevOps with Spring after linking it to a Kubernetes cluster please see https://www.youtube.com/watch?v=9D5TwMo-IIw https://www.youtube.com/watch?v=9D5TwMo-IIw We're considering renaming Auto DevOps to GitOps. What do people think?
- kronin 8y ago
  Please don't. I am using gitlab, though we quickly grew beyond auto devops. Your definition of auto devops is different than gitops. Gitops is the practice of using commits and pull requests to execute change and do releases. Weave uses it to mean git as the source of truth. https://www.weave.works/blog/gitops-operations-by-pull-request https://www.weave.works/blog/gitops-operations-by-pull-reque... Kelsey Hightower talked about it and and has demoed the workflow of using pull requests to initiate promotion and deployments. Gitlab's auto devops does not seem to tackle promotion via environment repos, so in my understanding does not fit gitops and would be confusing to call it such. Edit: Kelsey Hightower's kubeconf talk - https://www.youtube.com/watch?v=07jq-5VbBVQ https://www.youtube.com/watch?v=07jq-5VbBVQ And a better writeup on weave's site -https://www.weave.works/blog/gitops-high-velocity-cicd-for-kubernetes https://www.weave.works/blog/gitops-high-velocity-cicd-for-k...

kosta_self 8y ago

Does anyone have Jenkins in production and found it to be reliable and pleasant to use? I had to do lots of Jenkins integrations some time ago, and even though I tried to minimize the number of plugins and make things as simple as possible, things would randomly break from time to time or exhibit weird behaviour etc. I had the impression that Jenkins is deeply conceptually confused about some of its concepts, e.g. how builds are triggered. Also, it is a huge pile of untestable spaghetti code which explains the weird bugs. I modified an open-source plugin only to find out that it's almost impossible to write meaningful tests for it: you can't even mock Jenkins API without using the darkest Java mock magic. Jenkins classes are just written in an old style that makes testing _really_ hard but probably can't be changed without breaking all of Jenkins. I tried Jenkinsfile which was only even more unreliable (at the time at least, this was > 1y ago). The whole idea of using groovy, modifying the hell out of it to make it even more weird and surprising and edge-casy just didn't go well for me. I ended up with generating a _lot_ of very simple jobs for each project and connecting them via triggers instead. It was not very pretty, but it was the most reliable that I could get out of Jenkins. So the thought of integrating Jenkins deeply into you deployments, talking to Kubernetes and sitting in the middle of a huge pile of complexity (Jenkinsfile, Dockerfile, Helm, ...) and magic "that you don't need to worry about" scares the hell out of me. But then again, if you want to do CI/CD with Jenkins that's what you might want, right? (I would prefer more simple approaches if forced to use Jenkins, though)

abrookewood 8y ago
We use it in all of our environments and it is extremely flexible, mostly reliable, but still feels like a hodgepodge of plugins and various components. Once you throw in a variety of build tools and deployment options etc, it can get rather unwieldy. Still, we use it for almost everything now (no forgotten cron jobs running on random servers) and it gets the job done. I often think we should investigate other options, but we have made such an investment at this point it would be a massive undertaking to move to something else.
sammm 8y ago
I actually think Jenkins is way too flexible for most use cases. We moved to GitLab CI which isn't perfect, but it provides safety rails/structure/opinions that pretty much provides an answer for everything you want to do, apart from maybe obscure corner cases that might not make sense for a CI/CD tool anyways. Also you get the close integration of your CI tool and your git repos, which is very nice from a visibility point of view. Having said that, GitLab is trying to own all parts of the build and deployment process, which from previous HN discussions, is of great annoyance to a lot of people who want to cherry pick what they use GitLab for.

tirumaraiselvan 8y ago

If I understand correctly, this creates an environment for each PR. How does it accomplish that exactly? It would require all Kubernetes manifests for resources somewhere in the repo? What if the environment has some stateful dependencies, etc?

jstrachan 8y ago
Jenkins X creates a Preview Environment per Pull Request yeah; which can be as much or as little as you want it to be. e.g. it could be just 1 pod only or could be a suit of related apps (you may want to test multiple things together). You can define what a Preview Environment is in the source code of your application - its just a different Helm chart really. You can of course opt out of Preview Environments completely if you wish. http://jenkins-x.io/about/features/#preview-environments http://jenkins-x.io/about/features/#preview-environments Though I've personally found them to be super useful - especially if you are working on web consoles - it lets you try out changes visually as part of the Pull Request review process before you merge to master.
jstrachan 8y ago
BTW we're hoping to make it easier to 'service link' your Preview Environments to other environments. https://github.com/jenkins-x/jx/issues/573 https://github.com/jenkins-x/jx/issues/573 e.g. so you could deploy just your front end in a Preview Environment but link it to all the back end services running in the Staging or Production environment. Each team can configure their Preview environment helm chart however they wish really. Using separate namespaces in kubernetes is a great way to keep software isolated and avoids apps interfering with each other; but at the same time its really handy to be able to link services between namespaces too.

dankohn1 8y ago

Lots of innovation occurring in the CI/CD space around Kubernetes. We just added JenkinsX to the cloud native interactive landscape: https://landscape.cncf.io/grouping=landscape&landscape=ci-cd&selected=jenkins-x https://landscape.cncf.io/grouping=landscape&landscape=ci-cd...

adam-_- 8y ago

Presumedly this is only of interest for those running Kubernetes?

jstrachan 8y ago
Btw I’m the author of the above blog post & committer on Jenkins X. So our focus is currently anyone looking to automate CI/CD on kubernetes, the cloud or any modern platform like OpenShift, Mesos or CloudFoundry which all come with kubernetes support baked in. You can use just the CI part and do CI & releasing of non-cloud native apps if you want - we use Jenkins X to release jars, plugins & docker images using it - but doing so does miss out all the benefits of automated Continuous Delivery & GitOps promotion across environments

mekazu 8y ago

Just remember the name XKCD is already taken.

cfontes 8y ago

This looks like an improvement over what Jenkins 2.0 provides and I wish you guys good luck. I have used and vouched for Jenkins in several companies and some decent sized licenses were bought mainly because of my input. But to me, Cloudbees has done a major dick move making the stages not restartable in Jenkins 2.0, among other things. E.g: Dropping stage view out of nowhere and focusing only in Blue Ocean. I complained about in the channels that I had at the time and the response was, it's going to be unsupported from now on. It's a super squechy thing to have such a useful feature bundled with a bunch of support and useless stuff that I don't care, and then charge me per node. I am migrating away from Jenkins into GoCD after close to 10 years using it, and don't get me wrong I don't feel happy doing this, but it's hard to justify it. Fortunately the future looks bright, there are several interesting solutions available, Argo is super interesting to me, looking forward for Argo CD!

oblio 8y ago
They've changed their mind because of the community backlash: https://issues.jenkins-ci.org/browse/JENKINS-45455 https://issues.jenkins-ci.org/browse/JENKINS-45455
- cfontes 8y ago
  Thank you I did not know about that. Last time I checked with the sales guy it was not going to happen. I hope they improve their ways, it's a nice tool and I invested a lot of my time into it, but right now GoCD is my default option from now on.
  - moritzplassnig 8y ago
    If you have more feedback, I'm happy to connect with one of the PMs or somebody from the Jenkins OSS team. I'm the founder/CEO of Codeship and we got acquired by CloudBees earlier this year. And I want to make sure that Jenkins + all CloudBees products get better :)
    - cfontes 8y ago

jillesvangurp 8y ago

This solves part of a real problem. There are a lot of tools out there but end to end integration is left as an exercise to the reader. I'd love some out of the box sanity when it comes to devops, CI/CD, and cloudhosting. Instead I'm stuck building nw architectures, deployment scripting, dealing with archaic broken by default configs of misc bits and pieces, host configurations, build servers & CI/CD pipelines, etc. from scratch. Add log aggregation, security auditing, and other nice to haves that are actually not optional these days (what are you running blind and ignoring failed ssh attempts?) and you have a full explanation why so many companies make a mess of all of the above. IMHO a lot of stuff in this space are either focusing on making life harder through added complexity to up-sell support or more services or on solving a narrow problem in such a way that you have to still take care of a lot of other stuff.

C4stor 8y ago

Interesting annoucement, I'd like it better if there was a clear comparison between the current possibilities offered by Jenkins 2.0 and this version of Jenkins. I'm not huge fan of the demo video, since it doesn't really handle what I can only imagine is a very common use case : I already have a Jenkins 2.0 instance with Jenkinsfiles, how easy would it be to migrate to Jenkins X ? Is it isofunctional with added capabilities ? How much will I lose ? Bootstrapping a java spring app from scratch is fun, but I suspect most people have an already existing codebase with already existing CI/CD tools.

jstrachan 8y ago
That’s a great point. This blog tries to compare Jenkins X versus Jenkins 2.0: https://dzone.com/articles/jenkins-x-the-good-bad-and-ugly https://dzone.com/articles/jenkins-x-the-good-bad-and-ugly It’s mostly about automation of install, configuration, environments, pipelines & promotion with GitOps and more feedback. Just out of interest what kind of demo would you like to see?
tootie 8y ago
I'm leery of projects whose goal is make bootstrapping easier. Bootstrapping projects has generally gotten easier and easier and was never a real bottleneck. Projects spend 99% of their lifetime in development and maintenance so those are the parts that need the most help.

jdc0589 8y ago

Looks pretty cool. I really don't like the idea of my ci/cd tooling being responsible for provisioning its own k8s cluster....there are a lot of other more mature projects out there for doing this. Is the idea that the ONLY thing running on this cluster is jenkins-x and review/preview environments or something?

jstrachan 8y ago
Thanks! You are free to use any kubernetes cluster and install Jenkins X there: http://jenkins-x.io/getting-started/install-on-cluster/ http://jenkins-x.io/getting-started/install-on-cluster/ The default is to use separate namespaces in kubernetes for each teams developer tools & pipelines, Staging & Production environments (plus Preview Environments). Multiple teams can obviously use the same cluster with different namespaces. We’d expect ultimately folks may want to use a separate cluster for development & testing to Production. GitOps makes that kind of decoupling pretty easy but we’ve still work to do to automate easily setting up a multi-cluster approach: https://github.com/jenkins-x/jx/issues/479 https://github.com/jenkins-x/jx/issues/479

amq 8y ago

When I started using Travis I immediately got a fan of it. Not having worked with Jenkins before, when I first tried it (pre-blue ocean), I was shocked by the unnecessary complexity. Since then, I've settled with a self-hosted drone.io for private projects, it offers a very similar experience to Travis, while I don't feel like I'm lacking anything compared to Jenkins.

greenhatman 8y ago
Is the self-hosted version the same as the hosted enterprise version? Or are there features missing? Is it easy to self-host?

djabatt 8y ago

Automation is never easy. If you zoom your focus out watching the innovation in the ci/cd space is fascinating. Not to sound like an old fart but doing this all by hand back in the day sucked. Jenkins for us has made a lot easier. Curious to try GitLab and Jenkins X on a new projects

theptip 8y ago

Looks interesting, * I use one namespace per env (staging, prod, etc), is this supported or must I go with the default (slightly wacky) staging and prod releases side-by-side in the same namespace? * How are bugfix releases handled? If I pushed 1.2.0 to staging, and want to hotfix the prod release 1.1.0 with 1.1.1 (a common bugfix flow), can I promote releases from the hotfix branch? * Is there a permission model? Does it bottom out to GitHub permissions for each env repository? E.g. can I have a smaller set of users approved to promote releases to production?

jstrachan 8y ago
Each environment is in a separate namespaces. You can add/edit/delete the Environments to use whatever namespaces you wish to use. Promotion is either automatic or manual. By default Staging is automatic and production is manual. You can manually promote any version to any environment whenever you wish: http://jenkins-x.io/developing/promote/ http://jenkins-x.io/developing/promote/ For promotions we're delegating to the git repository for RBAC; so you can setup whatever roles you want for who is allowed to approve promotions & if you need code reviews etc

dcosson 8y ago

It's not completely clear to me from reading the site - does this run a non-dockerized app build in kubernetes, or does it also work for building and deploying my app as a docker container itself? This usually requires things like being able to spin up a cluster of containers per build - one with my app, one with a database to run against, maybe one with memcached or elasticsearch for integration tests, etc. And does it work out of the box for complicated cases like partitioning a large test suite to run in parallel, where each parallel part of the build needs its own mini cluster of a couple of containers talking to each other? I haven't looked into the current state of this recently but I ran into a lot of problems with this with a bunch of hosted CI services in the past. Somewhat ironically, as of a couple years ago if you needed to build your own docker container as part of a build you had to specifically stay clear of CI services that mentioned docker at all because that meant they were running their builds inside of containers and it was a pain to figure out how to run my own docker build, much less spin up a cluster per build with something like docker-compose, inside of a running container. Curious if and how Jenkins X solves this. Or have things changed and it's now easy to build and run docker containers inside of a container? (Aside from that, I'm not sure how I feel about Jenkins coordinating with a Kubernetes cluster. I've always found their monolithic approach to be a pain to work with, and always wished that, for example, I could just have Jenkins trigger jobs by pushing them onto an ActiveMQ queue or something and read back the results on another queue. Then I could just set up an autoscaling group of build servers, and provision them with whatever tools I'm already using to just start up and listen on this queue. Instead, jenkins wants me to duplicate a lot of this work I already have CM tools doing, and set it up manually through the UI, using community plugins that are often out of date).

kohsuke 8y ago
I defer the question about container building in Kubernetes to somebody from the Jenkins X team, but I wanted to respond to your side note. Offloading build queue outside Jenkins to another service, auto-scaling of build servers, configuring Jenkins with your configuration management tools are all something we are thinking about / looking into / actively working on. Some of them haven't gotten to the point of proper write-up yet, but see - https://github.com/jenkinsci/jep/tree/master/jep/201 https://github.com/jenkinsci/jep/tree/master/jep/201 - https://github.com/jenkinsci/configuration-as-code-plugin https://github.com/jenkinsci/configuration-as-code-plugin - https://github.com/kohsuke/jenkinsfile-runner https://github.com/kohsuke/jenkinsfile-runner

tra3 8y ago

I can't find this in the docs; but what happens when a promotion fails? Do things get rolled back to previous known state? The reason I ask is because I"m trying to replicate similar functionality in our much simpler environment.

jstrachan 8y ago
we're using helm for installing/upgrading apps; it takes care of reverting bad versions/releases etc
- tra3 8y ago
  Thanks, that's helpful, but we're not mature enough for k8s yet. What else can I look at?
  - jstrachan 8y ago
    if you can't use kubernetes or containers then I guess Ansible is a fallback?

tlynchpin 8y ago

Is it appropriate to compare this with OpenShift, and if so then what are the highlights of this comparison? I use Jenkins and k8s and the objective is generally Spring services, so it sounds like this is for me.

jstrachan 8y ago
OpenShift is Red Hat's supported fork & distribution of Kubernetes - so its another platform we can install and use Jenkins X on. OpenShift also includes some Jenkins support; e.g. you can add BuildConfig resources via a YAML file in the OpenShift CLI which will create a Jenkins server and a pipeline. But Jenkins X isn't yet integrated into OpenShift - but its easy to add yourself for now :) If you are pondering which kubernetes cluster to try for developing Spring services: OpenShift is a good option if you are on premise. If you can use the public cloud then GKE on Google is super easy to use; AKS on Azure is getting there & EKS is looking like it will be good if you use AWS. On the public clouds the managed kubernetes services are looking effectively free; you just pay for your compute + storage etc. So its hard to argue with free + managed + easy to use kubernetes - if you are allowed to use the public cloud!
- dankohn1 8y ago
  OpenShift is Certified Kubernetes, so not a fork. See: cncf.io/ck (Disclosure: I run the Certified Kubernetes program at CNCF.)
  - jstrachan 8y ago
    OpenShift is a fork of the Kubernetes code base: https://github.com/openshift/origin https://github.com/openshift/origin I.e. it’s not using the upstream distribution of Kubernetes like the public cloud vendors or Heptio etc. It’s great it’s a Certified Kubernetes though!
    - dankohn1 8y ago
      Fork has a perjorative meaning, as in taking it and going their own direction. I would describe OpenShift as a distribution.