Overview and documentation of the tooling used to drive while-true-do.io. Also, integrations from one service to another.
As a new contributor, I need an overview and documentation of tools that the project is using for certain tasks, so I can start working fast.
This repository describes the different services and tools that are used at while-true-do.io and are available for all contributors. If needed, it will also provide snippets, scripts and steps to reproduce the setup.
We are consuming several services as SaaS option. This makes it very easy to setup new stuff and get things going. Creating and maintaining our own infrastructure is still a thing, but first we want to get stuff done.
Ansible Galaxy is the most common way to publish Ansible content like plugins, roles, playbooks and collections. We also intend to publish our work there.
You can find a more detailed description here.
We want to automate a lot to reduce manual effort and establish a high quality of code. We opted for Cirrus, since it provides a nice integration in GitHub, a Command Line Interface and a cloud service, that can be used for free.
You can find some more details about Cirrus CI in the Cirrus document.
Docker Hub is the most common resource to store and search for container images. We are using it for all published images, too.
You can find a more detailed description here.
GitHub is our default place to store code, issues and everything related to coding. This decision was mostly made after testing a couple of alternatives like Gitea and GitLab. GitHub is still the standard to create, maintain and integrate Open Source projects and provides tons of functionality for free.
You can read more about our reasons and ways to use GitHub here.
LinkedIn is a business network to interact with companies and experts. It is very common to find tech enthusiasts on LinkedIn. We are using the platform mostly to send out updates and news or release announcements.
You can find some details about the integrations and reasons in the document about LinkedIn.
Shields are used in most repositories to display easy to access information about releases, builds and more. You can find more about this in the dedicated document.
Slack is the internal chat platform, used for dev-talk and most notifications. This decision was made after testing other options. Even if Slack is not a perfect solution, it gets things done, that need more manual work in other chat systems.
You can find more about Slack and how we use it here.
Twitter is a huge social network with lots of tech enthusiasts. It is easy to access, free and very widely used. At while-true-do.io, we use it mostly to keep users and contributors informed about new releases, blog articles or updates.
You can find all the details and integrations in this document.
UptimeRobot provides a very easy and convenient way to monitor infrastructure, web services and more. You are also able to provide a statuspage and alert integrations. The free plan allows us to monitor our services and get alerts in our preferred ways.
You can learn more about the usage and reasons at while-true-do.io in the documentation.
Zapier is the glue between the used services. If a service does not provide integrations in another service, we can most often use webhooks or other functionality via Zapier.
You can find a list of these integrations and the reasons behind the decision in this document.
At while-true-do.io, we agreed to use some software and ensure it is working as desired. Nobody is forced to use the same stack, but if you need some help from the community, it is recommended to check the default software.
For automation purposes, we use Ansible most of the time. Since Ansible provides options for setup and operations, it was chosen. It is also easy to learn and provides thousands of integrations.
If you intend to use Ansible or maintain Ansible Code, it is highly recommended to read our Ansible Documentation beforehand.
We want to automate a lot to reduce manual effort and establish a high quality of code. We opted for Cirrus, since it provides a nice integration in GitHub, a Command Line Interface and a cloud service, that can be used for free.
You can find some more details about Cirrus CI and Cirrus CLI in the Cirrus document.
Docker is the most known container software and also very well established in the tech industries. This document will cover the software (namely Docker CLI and Docker daemon) and why we are using it.
The Docker document provides some additional links and details.
For source code management, we use Git. You can find a very simple documentation in the Git document, the GitHub document and the Contribution Guide.
Since we already agreed on k3s as our Kubernetes distribution, we checked different ways of deploying k3s. The most interesting way was to have a "turnkey" solution like k3os.
You can read more about k3os and check our own documentation.
Using Kubernetes was somewhat mandatory to ensure that we can maintain our software in a declaritive and consistent way. After lots of investigation, we made the decision to use k3s as our base and focus on a Kubernetes-only workflow.
You can read more about k3s and check our own documentation.
On top of k3s, we are doing Kubernetes deployments and deploy containers. This was the most convenient way to establish a proper lifecycle management and ensure that nothing is changed by accident.
You can read more about the reasons and guidelines in the Kubernetes document.
Minikube is a CNCF certified software to run a very minimal Kubernetes instance on your local machine. This is extremely useful in development, since you don't require any central hardware.
You can find some features and reasons or useful links in the Minikube document.
Podman is a new Docker replacement, which provides a daemonless and rootless experience. Similar to Docker, you can build, run and publish container workloads with Podman. Instead of providing a seperate daemon, Podman is using many systemd mechanisms.
The Podman document provides useful links and some explanations, why we are using Podman.
With the decision of k3s and k3os we were also having a maintained option to configure, upgrade and maintain Kubernetes and the underlying Linux. The system upgrade controller from Rancher is our go-to-option.
You can read more about the decision and the features in this document.
Some of us are using VSCode or some fork of it like VSCodium for editing Kubernetes, Ansible, Container files and much more. There is a dedicated document providing some more details.
Thank you so much for considering to contribute! We are happy, when someone is joining the hard work.
Issues and Pull Requests are handled on a regular basis. Please be aware, that we may reach out to you, ask you to provide additional resources or want to discuss the issue a little, before planning it.
Providing code to this repository is pretty straight forward. Open an issue, so we can discuss the bug/feature and start working on it afterwards. You just need to open the pull request afterwards and that's it.
It is also strongly recommended to read the Contribution Guideline beforehand.
We are maintaining a changelog for repositories. Normally, the developers will update the changelog, according to keepachangelog.com.
To ensure a high quality and functionality, we want to carefully test our software. The provided code is automatically tested as described in the .cirrus.yml.
Except otherwise noted, all work is licensed under a BSD-3-Clause License.
Please feel free to reach out to us and the community. We also recommend to read and understand the Code of Conduct beforehand.