recipes VS charts

Here you go https://github.com/vabene1111/recipes/raw/develop/docs/logo_color.svg

This may be quite clear in its simplicity, and particularly to those familiar with etcha/jsonnet. However, what invariably happens is that you start seeing things like vars embedded in templates, embedded in the config mgmt implementation language, embedded in strings. The source of the values becomes incredibly difficult to reason about and to make changes against; does the value come from the target host's env, from the runner's env, from the packaging step's env, from a network request made by one of these stages (eg to a secret server), etc.

Take a look at an example of what, IMO, is an absolutely horrid helm chart that Gitlab ships for installing their CI/CD runner: https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/ma...

Bash code, in yaml, in golang template. Besides even the most advanced IDEs failing to grok such a freak of technical nature, there's no way I would believe any dev that told me they understand what the state of their system will be given some input to this morass.

In a recent position I was asked to try and make a nomad installation viable in a pretty standard corporate environment (not some special operational space e.g. cloudflare), and it was even worse; some configuration expansion was 5 layers deep, with 3 different templating engines, once consul templates were involved in generating an app's config, and the nomad config being env-generalized through generation by a higher-level helm-like tooling.

Re state bag:

I'm glad you mentioned nix, as I think it, and to a looser extent containers, really approach the issue in the only humanly-tenable fashion (again IMO): starting mutation from a known state. In a lot of cases that state is "nothing" as it's the simplest known state not only to position the beginning of some configuration flow at, but also the most straight-forward from which to deterministically derive a desired end state from.

I definitely applaud having tests as a core component of your system, the problem is that you can not derive determinism from nondeterminism even with the best tests.

Because you are operating over a nondeterministic bag of state, you can never guarantee that your tests provide a representation of a transfrom from any potential state to the desired end state, only for some particular input state (or set) which may or may not representative of what is found on the actual targets.

Here is the source for the GitLab Helm Chart. GitLab doesn't store the images for the GitLab Helm Chart on DockerHub; they store them in GitLab Registry. For example, the web service image by default is registry.gitlab.com/gitlab-org/build/cng/gitlab-workhorse-ee. This is listed here.

It kind of feels like Sid is lying through his teeth here, as a person who deploys and maintains a private Gitlab installation, along with a whole host of other core platform services for internal use. Gitlab is by far the most modular off-the-shelf product I've encountered outside of JFrog's Xray. Look at their official Helm chart: https://gitlab.com/gitlab-org/charts/gitlab. Gitlab itself consists of 14 sub-charts and it also bundles 4 third-party sub-charts for object storage, a web proxy and ingress controller, certificate management, and the internal container registry. Gitlab without the third parties I believe consists of 15 distinct containers.

I don't think it matches what most people think of when they hear "monolith." It is absolutely not a single process only communicating between components via function calls. Many of the Gitlab core services, such as Gitaly, are written in Go, as well, not Ruby, though they also have "gitaly-ruby" as a testing service that can be used by developers not comfortable with Go.

https://docs.gitlab.com/charts/ https://gitlab.com/gitlab-org/charts/gitlab

The GitLab Docker install instructions are for a monolithic image, but they do have separate images at https://gitlab.com/gitlab-org/build/CNG with Helm charts to configure them at https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/

[1] https://www.scaleway.com/en/docs/compute/kubernetes/api-cli/creating-managing-kubernetes-lifecycle-cliv2/ [2] https://gitlab.com/gitlab-org/charts/gitlab-runner/-/blob/main/values.yaml [3] https://about.gitlab.com/blog/2017/09/05/how-to-automatically-create-a-new-mr-on-gitlab-with-gitlab-ci/

For work we're on Gitlab Enterprise, but I run custom ci runners from the chart. They're registered to my org, so any project in my org can issue jobs.

Error logging in to endpoint, trying next endpoint" error="Get https://registry.192.168.49.2.nip.io/v2/: x509: certificate signed by unknown authority" Looking at the certificate: - Issuer: O = default, OU = gitlab, CN = GitLab Helm Chart - Subject: CN = 192.168.49.2.nip.io Steps to reproduce: (1) minikube start --addons=registry,dashboard,ingress \ --apiserver-names=apiserver.k8s,apiserver.kube-system.svc.cluster.local \ --apiserver-ips=192.168.49.2 (2) https://gitlab.com/gitlab-org/charts/gitlab.git (3) cd gitlab helm dep update helm upgrade --install gitlab . \ --timeout 600s \-f values-examples/values-minikube.yaml \ --set global.hosts.domain=$(minikube ip).nip.io \ --set global.hosts.externalIP=$(minikube ip) (4) push a random spring job into it https://github.com/paulczar/spring-helloworld

https://gitlab.com/gitlab-org/charts/gitlab-runner/blob/master/values.yaml#L432