Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jenkins.io

Post reply on HN
Print view View original

91–100 of 106 posts

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

#91

Post by jstrachan »

tlynchpin wrote: post #76

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.

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!

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

#92

Post by joshlambert »

sammm wrote: post #84
sytse wrote: post #62

Earlier quoted context omitted.

Thanks for using GitLab. We want to be supportive of cherry picking GitLab features. For example we just release CI/CD with GitLab for GitHub https://about.gitlab.com/features/github/ Is there something we can add to GitLab to make it more composable?

Thanks for the question, greatly appreciated. We used GitLab on k8s when we first transitioned, but we found there were a few things we didn't quite like about the GitLab-Omnibus helm setup, so we moved it off the cluster and used the AWS EC2 AMI which was really easy to setup. We are going to start experimenting with the new cloud native GitLab chart, but it would need to gain some maturity before we use it in produ…

samm we are indeed making all components that are not core gitlab services optional. You will be able to turn them off with a simple `prometheus.enabled=false`.

Thanks for giving the charts a try in alpha/beta, please pass along any feedback. We'd love to get it!

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

#93

Post by theptip »

sytse wrote: post #73
theptip wrote: post #64

Earlier quoted context omitted.

How are you liking GoCD? I've been looking for an alternative to GitLab for a while.

What can we improve in GitLab that would make you stay?

Thanks for taking the time to ask.

My primary concern is that instead of polishing the features that have already been released, the platform is trying to do too many new things. Some of that stuff is cool (k8s monitoring integration, though EEP is too expensive for me, and my Grafana dashboard does basically the same thing), while some of it seems a bit bloated (SAST/DAST for example, which was a few lines of code to implement ourself).

I really want the core Github replacement use-case to be as ergonomic as Github is. And the CI/CD piece is also great, but still has plenty of rough edges (e.g. Environments are a great feature, but I still can't clean up stale ones, which makes the environment list basically useless).

My experience with support has been a bit lackluster; e.g. see https://news.ycombinator.com/item?id=16897644.

General reliability in CI/CD is not great; I'd say something like 0.25-0.5% of my build jobs fail from intermittent infrastructure failures (mostly gitlab runner/API issues from what I can tell), which wasn't a problem when I was using Jenkins.

Ops is still a significant concern; site reliability has improved in the last year, but that's not saying a lot; it's still a fairly frequent occurrence to get errors during/after a deploy. I'm not sure if this problem would be better or worse if I self-hosted, as I don't know how hard it is to run a GL instance (seems like it's hard, given how often the gitlab.com site has issues).

Performance has also improved in the last year, but the site is still on the slow side (e.g. compared to contenders like gitea).

Oh, and the pricing model is a bit broken -- all of the other SaaS platforms that I use let me pay monthly (at a higher rate); when I was evaluating paying for gitlab.com vs. doing self-hosted EE, I really wanted to pay for my team to use the hosted offering for a few months to see how things went, but I wasn't prepared to lock in for a year, so I didn't end up trying out the hosted paid offering.

None of these points in isolation is enough to make me leave the platform and go back to Jenkins, but they are enough to make me pay close attention to the alternatives.

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

#94

Post by tra3 »

jstrachan wrote: post #90
tra3 wrote: post #71

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.

we're using helm for installing/upgrading apps; it takes care of reverting bad versions/releases etc

Thanks, that's helpful, but we're not mature enough for k8s yet. What else can I look at?

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

#95

Post by dankohn1 »

jstrachan wrote: post #91
tlynchpin wrote: post #76

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.

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 whic…

OpenShift is Certified Kubernetes, so not a fork.

See: cncf.io/ck

(Disclosure: I run the Certified Kubernetes program at CNCF.)

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

#96

Post by jstrachan »

dankohn1 wrote: post #95
jstrachan wrote: post #91

Earlier quoted context omitted.

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 whic…

OpenShift is Certified Kubernetes, so not a fork. See: cncf.io/ck (Disclosure: I run the Certified Kubernetes program at CNCF.)

OpenShift is a fork of the Kubernetes code base: 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!

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

#97

Post by jstrachan »

tra3 wrote: post #94
jstrachan wrote: post #90

Earlier quoted context omitted.

we're using helm for installing/upgrading apps; it takes care of reverting bad versions/releases etc

Thanks, that's helpful, but we're not mature enough for k8s yet. What else can I look at?

if you can't use kubernetes or containers then I guess Ansible is a fallback?

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

#98

Post by pas »

InternetOfStuff wrote: post #85
sytse wrote: post #73

Earlier quoted context omitted.

What can we improve in GitLab that would make you stay?

Sytse, thanks a lot for being present in the community. It's most appreciated, and I always look forward to your comments. With regards to your question: I agree with user kerny. Stop packing stuff on top. What I want from Gitlab is to use it to manage my repos. If you improve that aspect (which is already fine though IMO), you'll make me happier. If you improve Gitlab integration with other CI tools, you'll make me…

GitLab does one thing. And GitLab CI/CD does one other thing. GitLab Image Registry does yet an other thing pretty well.

And GitLab Omnibus also does one thing. (It bundles those.)

Making it more configurable (as in makeing more features disable-able) would be nice though.

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

#99

Post by pas »

theptip wrote: post #93
sytse wrote: post #73

Earlier quoted context omitted.

What can we improve in GitLab that would make you stay?

Thanks for taking the time to ask. My primary concern is that instead of polishing the features that have already been released, the platform is trying to do too many new things. Some of that stuff is cool (k8s monitoring integration, though EEP is too expensive for me, and my Grafana dashboard does basically the same thing), while some of it seems a bit bloated (SAST/DAST for example, which was a few lines of code t…

> SAST/DAST for example, which was a few lines of code to implement ourself

Could you elaborate on that please?

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

#100

Post by dankohn1 »

jstrachan wrote: post #96
dankohn1 wrote: post #95

Earlier quoted context omitted.

OpenShift is Certified Kubernetes, so not a fork. See: cncf.io/ck (Disclosure: I run the Certified Kubernetes program at CNCF.)

OpenShift is a fork of the Kubernetes code base: 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!

Fork has a perjorative meaning, as in taking it and going their own direction. I would describe OpenShift as a distribution.
Post reply on HN