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

Beyond CI/CD: GitLab's DevOps Vision (2017)

about.gitlab.com

Post reply on HN
Print view View original

61–70 of 72 posts

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#61

Post by tazjin »

ianwalter wrote: post #57
tazjin wrote: post #7

Slightly offtopic from what the article focuses on, but the thing that bothers me about all these built-in CI/CD things in software like Gitlab is that people seem to be perfectly content with building an artifact and then just ... pushing it out. In traditional deployments that may be some kind of "copy this thing over SSH and make it go!", in Kubernetes-land it's more like "lets just modify this API-state to point…

What about Helm?

I aim for as few moving components at runtime as possible. Helm has tiller, which I'm not a big fan of.

In addition its design (with warts like the separate versioning layer of charts) adds complexity that I don't think is necessary for most use-cases.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#62

Post by joshlambert »

therealmarv wrote: post #9

I don't get the beyond part, especially monitoring.... will Gitlab only have a Prometheus view in their UI or do they want to create their own monitoring? And when using own monitoring... this is a bit crazy... we have from day to day more and better Prometheus for that.

We are indeed leveraging open source tools like Prometheus, and not seeking to build our own. We do believe however that the data and insights that Prometheus provides can be much more impactful to an organization if it is provided in the workflow that developers already use, rather than a separate tool/UI.

For example when looking at a CI/CD deploy to an environment, you can easily access important Prometheus metrics and in the future logs, from the same console.

This also allows us to build more intelligence into the platform, as GitLab is more aware of your application and its health. One example is to incorporate Prometheus monitoring to compare the performance of a new release in an incremental deployment, and automatically pausing it if key metrics have degraded.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#63

Post by plange »

tazjin wrote: post #31
akvadrako wrote: post #21

Earlier quoted context omitted.

Sorry but it's not clear what you are saying. What is the fundamental difference between modifying your k8s deployment to point to a new tag and your solution? You can easily roll back (except with database migrations) and easily see what version is deployed when.

When you update a Kubernetes deployment in the API directly you're essentially modifying a global variable. If you do this as the result of some imperative process (e.g. a CI pipeline), you don't have any record telling you what the value should be - you only know what it currently is . You're also only modifying a single piece of your whole state at any given time, meaning that if you have the services A and B and t…

I had this exact same problem with the way i & my team approached our kubernetes clusters. I come from a network management background and in that space we all know of a tool called RANCID. A simple tool that logged into your switches/routers, made a dump & removed counters/oscillating data and stored it into CVS.

This predates infra-as-code.. it took years before someone wrote a clone that used Git instead of CVS

Made something stupidly similar for kubernetes: https://github.com/pieterlange/kube-backup

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#64

Post by Kihashi »

rdsubhas wrote: post #14

We have explored GitLab in the past and a lot of our CI/CD is heavily inspired from GitLab. They seem to be consistently taking right decisions at the micro level. Their CI/CD design and execution is way more usable and reliable than pipelines (still no manual stages, still no re-triggering, etc). Their design and integration with Kubernetes is also a great choice. So on the micro picture, things are quite good. On t…

> None of these are instrumentable/hookable. Want to enforce some of your own organization policies before deployment? Want to use everything _except_ with your own monitoring tool? Sorry. If you use GitLab, you use their universe and everything that comes with it. There is no graceful integration with a broader set of tools.

Huh? Gitlab has a huge list of integrations[1] and webhooks[2]. You can use Jira for issue tracking or Jenkins for CI, for example. If something is missing, it's open source, so the plugin can be added by the community if need be. The software itself is hugely configurable for different workflows and team structures. Can you be a little more specific on what Gitlab is doing poorly here?

[1]: https://docs.gitlab.com/ce/user/project/integrations/project... [2]: https://docs.gitlab.com/ce/user/project/integrations/webhook...

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#65

Post by burner5308 »

chrisshroba wrote: post #59
d33 wrote: post #24

Earlier quoted context omitted.

> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous atti…

In your opinion, what is a valid reason for software to be non-open source? Sure, saying the software doesn't "deserve" to be open source might be a bit extreme, but I keep seeing the sentiment on HN that free and open source is the only allowable route and people who want to charge for their software are to be demonized. I'm curious under what circumstances you think it is allowable for a company to profit off of so…

There's no reason for any software not to be open source, aside from greed.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#66

Post by foepys »

piaste wrote: post #56
foepys wrote: post #6

Earlier quoted context omitted.

Gitlab in a way suffers from being open source. Their open source product is so good and includes so many features (even a full featured CI/CD pipeline!), that they need something big to justify their paid version. So I don't blame them. You can disable a lot of stuff that eats away your memory.

> You can disable a lot of stuff that eats away your memory. Can you give some examples, and/or a link? I like using Gitlab as an easily portable, one-docker-container-and-you're-running hosting service, so it would be nice to make it more lighteweight.

In the gitlab config file you can disable Mattermost and Prometheus which both use quite a lot of memory.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#67

Post by some_account »

d33 wrote: post #24
eadz wrote: post #18

I like gitlab, but a mixed open source / closed source product is always going to be a challenge in terms of hearts and minds. Take this quote from the article. > The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.

> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous atti…

Look at what the free version offers. They are extremely generous with what they are putting in it, and it's super high quality. I'm very happy with it and I think they are doing everything right. Their platform is a joy to use.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#68

Post by d33 »

chrisshroba wrote: post #59
d33 wrote: post #24

Earlier quoted context omitted.

> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous atti…

In your opinion, what is a valid reason for software to be non-open source? Sure, saying the software doesn't "deserve" to be open source might be a bit extreme, but I keep seeing the sentiment on HN that free and open source is the only allowable route and people who want to charge for their software are to be demonized. I'm curious under what circumstances you think it is allowable for a company to profit off of so…

There seems to be a lot of confusion around free software and open source. You can sell open source software (as a matter of fact, you can sell free software too). First of all, open source only means that source is available - the license is up to the developer though and it might as well be paid for commercial use etc. "Free" has two meanings - "free of charge" and "free as in freedom". I'm not arguing for "free of charge" - while it's nice to have software that you don't have to pay for, I could imagine, say, buying Microsoft Windows if I had access to the source code and could hack it as I go.

"free as in freedom" means that I can not only access the code, but also redistribute it and use it in any way I see fit. This doesn't mean that the developers can't sell it though - they can sell support, extra features, hosting and so on. There are ways to profit from free/open source software. I could as well imagine Gitlab Foundation and Gitlab Ltd, where one provides the core and the other non-free modules that cover enterprise use cases. I don't like their current scheme though.

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#69

Post by d33 »

some_account wrote: post #67
d33 wrote: post #24

Earlier quoted context omitted.

> The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. Did they actually say that...? I only went to the page to confirm this and it appears true. Sounds like next time I choose self-hosted Github alternative, I should exclude Gitlab from my options - based on their approach so far, it feels like they really do mean this kind of contemptuous atti…

Look at what the free version offers. They are extremely generous with what they are putting in it, and it's super high quality. I'm very happy with it and I think they are doing everything right. Their platform is a joy to use.

I disagree, but it could be that we're using Gitlab differently. I used to be very enthusiastic at first, but over time I got annoyed by its quirks and decreasing amount of attention to CE. Could you tell more about how you use Gitlab? For example, is it self hosted?

Re: Beyond CI/CD: GitLab's DevOps Vision (2017)

#70

Post by Snappy »

eadz wrote: post #18

I like gitlab, but a mixed open source / closed source product is always going to be a challenge in terms of hearts and minds. Take this quote from the article. > The other way to look at it is that this is pretty advanced stuff, and frankly, it doesn’t deserve to be, free, open source. So is all the stuff that gitlab builds on, like git, or ruby, or linux, that's all pretty advanced stuff I'd say.

Thanks for pointing this out. Changed with https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/....

Advancedness is not a criteria in open sourcing or not open sourcing. There are advanced features that are open source, such as Review Apps[0]. There are basic features that are proprietary, such as File Locking[1]. The criteria we use to decide which version the features go in are documented on our stewardship page[2].

[0] https://about.gitlab.com/features/review-apps/ [1] https://about.gitlab.com/features/file-locking/ [2] https://about.gitlab.com/stewardship/#what-features-are-ee-o...

Post reply on HN