selfhost VS compose-spec

I just started using Pyinfra to wrangle a bunch of servers and it is a breath of fresh air compared to Ansible. I moved all of my server OS installs to Fedora CoreOS which doesn't ship with Python in the OS and since Pyinfra doesn't need Python on the host node I can kick off tasks in bulk to do server things. It is great. I cannot wait to see where the Pyinfra project goes.

On a side note, one of the most hacky things I came up with to get Ansible working on Fedora CoreOS was to bind mount a container rootfs that had python 3 and then symlink it into the right spots. You can of course add Python in with rpm-ostree if you want but I wanted to avoid layering packages at the time. I wasn't proud of it. But it worked.

https://github.com/forem/selfhost/blob/main/playbooks/templa...

This is not the suggested way of deployment by the forem team, nevertheless I found it easier and smother than using the deployment selfhost, however I think it's good to know different approaches and use the one suits you the most, if you don't have time to manage a server I think using a pass like Render does the job, and it's cheaper then Heroku at the time of this post.

Forem Self-Host. You should probably know Forem. But in case you don't, just know that DEV is hosted on it.

I only use Podman for my workloads these days. Docker was always a headache for me on Linux. Podman allows me to quickly do whatever I want with containers and I can use systemd or a simple bash script to easily create services on my workstation or in production with Nomad with https://github.com/hashicorp/nomad-driver-podman

I am super thankful for the team of developers that work on Podman. It has really come a long way since 2.0 and they are very responsive to issues in my experiences. If you are using Linux as your daily driver and you use Containers give Podman a try. Here are some examples of the things I have done with Podman.

https://github.com/forem/selfhost

https://github.com/jdoss/ppngx

https://gist.github.com/jdoss/25f9dac0a616e524f8794a89b7989e...

https://gist.github.com/jdoss/ad87375b776178e9031685b71dbe37...

To automatically generate a TOC, you can use an online tool like the GitHub Wiki TOC generator. I used this tool to create the TOC in Forem’s Selfhost project when I was a developer advocate there.

Hi, everyone; I just tried the tutorial for deploying a self-hosted instance of forem (https://github.com/forem/selfhost) on AWS. A step in the tutorial asks for the creation of an AWS user with Programmatic access called forem-selfhost with the following

We (I work for Forem) have an opensource selfhost installer [0] so you can have total control over your data and community too.

[0] https://github.com/forem/selfhost

If you know what Forem you want to build, please follow the instructions and go live — again, the Self-Host instructions are available here!

Specification: https://compose-spec.io

https://github.com/compose-spec/compose-spec/blob/master/spe...

There are a number of incorrect statements in this post.

1) One should neither be using the "latest" nor just the "version" tag as the version can still vary depending on when it is pulled.

Instead, one should use a combination of version + hash, say alpine:3.18.2@sha256:82d1e9d7ed48a7523bdebc18cf6290bdb97b82302a8a9c27d4fe885949ea94d1 for reproducibility reasons. This provides for human readable versions as well as the specific hash.

2) Next, afaik, Compose has removed the need for version tags. All of the compose.yml files that I now use do not specify versions.

See https://github.com/compose-spec/compose-spec/blob/master/04-...

Docker Compose v2 specifications provide a useful Secrets feature which may also be used for standalone Compose Application Stacks and not just in Docker Swarm mode. With Docker Secrets the environment variables that contain credentials for other subsystems are mounted into the Telegraf Container as files. These secret files are read through the Docker Secret Store plugin and passed to the respective plugins in a relatively safe manner. By using the Docker Secret Store Plugin, one can also avoid credentials that were previously visible via environment variables, to be now hidden behind runtime secret files within the container. Standard Method with Environment Variables As an example, it is possible to pass the credentials to a plugin via the environment variable placeholder in a telegraf configuration file where the credentials for a plugin exist in a .env file (e.g. MQTT input Plugin)

also the docker-compose.yml file is very picky about what you have in it and where. Please read this so you know how to format it https://github.com/compose-spec/compose-spec/blob/master/spec.md

As part my quadlet helper tool, podlet, I'm adding functionality to convert compose files into k8s yaml to use with quadlet as an alternative to creating a bunch of separate quadlet files, which I've also added functionality for. So I would like to be able to transform the options on compose volumes into k8s yaml. For example, using the volume.podman.io/driver annotation to change the volume driver for a specific volume if possible.

If you find this helpful feature, please leave your feedback and suggestions here.

The compose spec will give what you need. https://github.com/compose-spec/compose-spec/blob/master/spec.md

Indeed, as per the compose-spec a lot of what was version specific is going away

Hello everyone, I just made a tool to visualize compose files, and all the parsing rules follow the [compose-spec](https://github.com/compose-spec/compose-spec/blob/master/spec.md). I hope this tool will help you :D