Implemented Features
This is a list of notable features that have currently been implemented.
-
Not coupled to Source Control Management (SCM) software.
-
A site is deployed via a site configuration file.
-
Each site configuration defines a 'release' tar.gz file which contains the source code for the site. The release tar.gz file can be referenced locally via absolute file path or downloaded from a URL.
-
Deployments will effectively skip already deployed sites based on the version string of the site.
-
-
Supported language handlers for services
-
Python WSGI or ASGI managed by Gunicorn
-
Python workers
-
Chill with dynamic or static deployment
-
Immutable services with resources stored on S3 object storage or disk
-
podman to run containers
-
Image is loaded from the artifact tar.gz
-
Networking for containers is limited and only allows ingress. No egress to other services on the box from a container.
-
-
Compiled binaries
-
Scheduling commands with crontab
-
-
The build and install of Python service dependencies only use local dependencies referenced by a requirements.txt file in the versioned artifact. The pip install --no-index … command is used when installing Python services on the chillbox server for better security.
-
Each site can use and configure a secure Redict instance that is only available on a unix socket. Only the site’s services and workers can access it.
-
Website services run on Alpine Linux and don’t use systemd
-
Support deploying to either Alpine Linux or Debian
-
With Alpine Linux; OpenRC and s6 is used instead of systemd to align with the goal of using less software. Also see A word about systemd from the author of s6.
-
Debian is supported because most cloud hosts don’t offer Alpine Linux as a Linux distribution.
-
Doing a
chroot
install of Alpine Linux on an existing deployed server running Debian is non-trivial in my opinion, and creating a custom Alpine Linux image for a cloud host has some drawbacks.
-
-
Shell scripts are POSIX compliant
-
Website configuration is in either JSON or TOML.
-
No remote build pipeline, all builds happen on the local host machine
-
Secrets are encrypted and stored securely on the host machine
-
Secrets used on the chillbox server are encrypted to a public key, the private key is generated on the chillbox server and never stored elsewhere.
-
-
Start long running worker processes defined by the site. Support using RQ, ARQ, or a custom run command. Allow running multiple copies of them.
Other Ideas for New Features
These ideas might be a bit outside of the goals and are not part of any immediate use case that I currently have. These are the things I would be tempted to implement.
-
Deploy multiple chillbox servers for high availability
-
TODO: Find other cloud hosting providers that do this?
-
Deploy multiple chillbox servers to different regions and improve response time with GeoDNS
-
Option to use a managed DNS provider that has GeoDNS
-
Support other language handlers for services
-
Batching large jobs by spinning up temporary resources
-
Support for running OpenFaaS functions with faasd
-
Monitoring and ability to easily view logs without being on the server
-
Locking down a server and making it immutable, disabling SSH, auto shutdown if a process is executed that is not in the accept list.
Out of Scope Features
This project may not be a good fit for someone expecting a fully finished and battle tested solution.
-
Use of cloud hosting provider services that have expensive bandwidth costs (free tiers and such are not considered)
-
AWS CloudFront - 0.085 per 1GB transfer out
-
AWS EC2 and other compute - 0.09 per 1GB?
-
AWS S3 Buckets - 0.09 per 1GB?
-
-
Auto scaling resources
-
Deployments triggered by version control (GitOps)
-
Dependency on any specific solutions provided by a single cloud host (vendor lock-in)
-
No virtual machines like Firecracker
Alternatives
I suggest looking at other alternative solutions if Chillbox and the shell scripts involved don’t meet your needs. This project is being developed by myself (Jake Hickenlooper) and I may break existing functionality with any updates.
I’m aware of these other projects that start with "K":
-
Kubernetes, also known as K8s, is an open source system for automating deployment, scaling, and management of containerized applications.
-
K3s - Lightweight Kubernetes
-
k0s - The Zero Friction Kubernetes
-
Kamal - Deploy web apps anywhere