charts VS eksctl

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

There are a variety of ways in which you can create an Amazon EKS cluster. I prefer using eksctl CLI because of the convenience it offers. Creating an an EKS cluster using eksctl, can be as easy as this:

There are many ways to create a cluster such as using eksctl. In my case, I will use terraform module cause it’s easy to reuse and comprehend.

eksctl [eksctl] is the tool that can provision EKS cluster as well as supporting VPC network infrastructure.

For this and many other reasons I recommend doing everything in Terraform EXCEPT EKS and its node groups. For that, I use https://eksctl.io/ because it much better manages the lifecycle of EKS and your node groups. I have an blog article better explaining why I recommend it, and another blog article explaining how to do zero-downtime upgrades with EKSCTL.

eksctl

Second, make sure you create a spot instance group that attempts to launch MULTIPLE different instance types. This way if one instance type gets flushed, your autoscaler will kick in and launch a different type. Without this, you WILL HAVE DOWNTIME if a sudden price hike and flush occurs. If you're using eksctl I have example configurations that use multi-instance types on Github here.

There are a variety of ways in which you can create an Amazon EKS cluster. I prefer using eksctl CLI because of the convenience it offers. Creating an an EKS cluster using eksctl, can be as easy as this:

I've written an article on this, with my recommended tool for managing eks EKSCTL.

--- AWSTemplateFormatVersion: '2010-09-09' Parameters: VpcId: Type: AWS::EC2::VPC::Id Description: ID of the VPC in which to create the Kubernetes cluster SubnetIds: Type: List Description: List of Subnet IDs in which to create the Kubernetes cluster KeyPairName: Type: AWS::EC2::KeyPair::KeyName Description: Name of the EC2 Key Pair to use for SSH access to worker nodes ClusterName: Type: String Description: Name of the Kubernetes cluster to create Resources: ControlPlaneSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref VpcId GroupDescription: Allow inbound traffic to the Kubernetes control plane SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 0.0.0.0/0 WorkerNodeSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: VpcId: !Ref VpcId GroupDescription: Allow inbound traffic to Kubernetes worker nodes SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 0.0.0.0/0 ControlPlaneInstanceProfile: Type: AWS::IAM::InstanceProfile Properties: Roles: - !Ref ControlPlaneRole ControlPlaneRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy - arn:aws:iam::aws:policy/AmazonEKSServicePolicy ControlPlaneInstance: Type: AWS::EC2::Instance Properties: ImageId: ami-0b69ea66ff7391e80 InstanceType: t2.micro KeyName: !Ref KeyPairName NetworkInterfaces: - DeviceIndex: 0 AssociatePublicIpAddress: true GroupSet: - !Ref ControlPlaneSecurityGroup SubnetId: !Select [0, !Ref SubnetIds] IamInstanceProfile: !Ref ControlPlaneInstanceProfile UserData: Fn::Base64: !Sub | #!/bin/bash echo 'net.bridge.bridge-nf-call-iptables=1' | tee -a /etc/sysctl.conf sysctl -p yum update -y amazon-linux-extras install docker -y service docker start usermod -a -G docker ec2-user curl -o /usr/local/bin/kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.21.2/2021-07-05/bin/linux/amd64/kubectl chmod +x /usr/local/bin/kubectl echo 'export PATH=$PATH:/usr/local/bin' >> /etc/bashrc curl --silent --location "https://github.com/weaveworks/eksctl/releases