Bootstrapping.

[codefriar]

Ok, so I've gone down the path of automating the k3s install with Ansible, and I've started writing the Ansible tasks for setting up the various namespaces etc that @evanmn and @kpoppel pioneered.

But I'm not sure it's worth it. We could just as easily (maybe easier) write a shell script for people to run on the server to get k3s, traefik2, helm etc. installed.

What do people think?

[voryzen]

There is no benefit to using Ansible? Setting of variables.. anything?

Btw '@ALL' doesn't work in github, not like it does in gitlab

[denis-ev]

I like ansible, just to get the servers up and running. That should stay as is.

For everything that can be installed, I would not mind a shell script.

[ghost]

Not sure how practical this is but if I was a user of this project looking for an easy setup, I would want to run a shell script on my local machine, enter the info of the server and have everything installed on the server from my machine. It could also just a script to curl | bash on my server.

My understanding is ansible is great for larger deployments and can be used for smaller but might not be necessary. One drawback of the script over ansible is that while it is easier in the short term, it may prove more difficult to maintain.

[kpoppel]

When looking at how the tutorials go, and the wiki pages we have collected here, then it is a matter of how far from "i have a blank PC", we'd like to start. If the assumption is that we have a person with a freshly debian-netinstall PC or RPi, then there are a few step to do first, before PetriPod can be applied. If however the assumption is that we have a machine with prerequisites (sudo, curl for instance), and SSH keys already done, then the initial deployment is just a bash thingy... Well actually I think the Task-stuff that @codefriar made should immediately be ported to here :-)

Ansible: If we need something to be idempotent - great idea. If not? the it is just adding more client machine dependencies to take care of, resulting in more bash scripting or more documentation.

So what do I think? I think go for Bash/Task first, and assume the starting point is as ready as can be, i.e. sudo, ssh keys, curl etc. is present. We can always dig deeper, but let's get the basics done first, make it easy to add and maintain the core and services, then dive into "I have a PC and blank SSD drive, now what?"-pool.

[codefriar]

The more I look into this, the more I think ansible is a better tool for the job. We’ll want to do things like add lines to fstab and ansible already has the capabilities to do it.

[codefriar]

Team, Ansible has a fairly robust k8s module, but it's pretty tedious. here's an example:

- name: Create CustomResourceDefinition for Traefik Middleware
  k8s:
    state: present
    definition:
      apiVersion: apiextensions.k8s.io/v1beta1
      kind: CustomResourceDefinition
      metadata:
        name: middlewares.traefik.containo.us
      spec:
        group: traefik.containo.us
        version: v1alpha1
        names:
          kind: Middleware
          plural: middlewares
          singular: middleware
        scope: Namespaced

The alternative is to create the ymls and use ansible to drop them in a specific place and call kubectl from there. I'm leaning towards just writing the yml and dropping it in place. That begs the question ... where to put them?

[ghost]

Here is the kubectl yaml version of that. It looks a bit tedious but all it really adds is the four lines at the top, two of which look to be the same across all defenitions. I think that dropping yaml and calling kubectl would just be adding unnecessary confusion to the mix.

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: middlewares.traefik.containo.us
spec:
  group: traefik.containo.us
  version: v1alpha1
  names:
    kind: Middleware
    plural: middlewares
    singular: middleware
  scope: Namespaced

[codefriar]

@evanmn just to clarify, you're for using the Ansible k8s bit, not dropping yml files and calling kubectl?

[ghost]

Yes.