Dad's Garage

Dad's Garage is a container that has all of the build tools you need to build, test, and deploy a cloud-native application to Kubernetes. The idea is to

1. Be able to develop your application on a computer that has nothing but an IDE and a container runtime (Docker, Podman, etc) by using Dad's Garage as the "developer toolbox".
2. Use Dad's Garage in your CI/CD pipeline to build, test, secure, deliver, and deploy your application to Kubernetes.

It's the containerized version of your dad's garage. It's full of tools, you spend lots of time in it, and you use it to build great things.

Dad's Garage is very new, and many of the tools that you will need to use aren't there yet. Stay tuned, or contribute by submitting a pull request!

What Dad's Garage is (or will be)

• A container full of tools that follows best practices for security and usability
• A Jenkins JNLP Agent
• A Selenium Server
• Maybe more???

What Dad's Garage is not (and never will be)

• A small container. As tools are added it is likely the container will grow to several gigabytes. This is expected and should not be seen as an issue, since this container will act as the main toolkit for develoeprs to use to develop with.
• A container that is used to run applications in production. Don't do this! Production containers should be tiny, only installing what is absolutely necessary to run.
• A windows container. You won't be able to build .NET Framework apps with this. (.NET Core should work great though!)

Usage

Our goal is to make Dad's Garage as simple as possible to use. A user should be able to pick up DG and use it with no required configuration.

Developer Experience

The most basic way to use DG, is to just use docker run

docker run -it --rm dadsgarage/dadsgarage:latest bash

But that's not very useful, since it doesn't have your source code, or any of your other files on your system that are necessary to get your work done. Here's a more complete example:

docker run -it --rm \
  --mount type=bind,source=$HOME/.cache,target=/home/dadsgarage/.cache \
  --mount type=bind,source=$HOME/.ssh,target=/home/dadsgarage/.ssh \
  --mount type=bind,source="$(pwd)",target=/home/dadsgarage/workdir \
  --workdir /home/dadsgarage/workdir \
  dadsgarage/dadsgarage:latest \
  bash

Now we're talkin'! We've got a bash shell inside the container, with the current working directory, as well as $HOME/.ssh for connecting with the git repo using your SSH key, and $HOME/.cache for caching pre-commit's environments so you don't have to build them every time. This is a command that you can alias or create a shell script for in your path so you can run it easily.

For more examples of how to use tools installed in the container, see the examples folder.

Continuous Integration

Work in progress, check back later.

Tool Versions

Most installed tools use the Dockerfile's ARG command for the tool version, so you are free to build the tool yourself using the --build-arg flag. Example:

docker build src/docker -t dadscustomgarage:latest --build-arg PRE_COMMIT_VERSION=1.19.0

This will build the container with pre-commit v1.19.0 instead of whatever is specified in the dockerfile. You can use as many --build-arg parameters in a docker build command that you want. Inspect the Dockerfile for the list of available ARGs and the syntax for each one.

The list of ARGs are scattered throughout the Dockerfile in order to preserve caching. If all of the ARGS were collected at the beginning, each change to the version of any tool would bust the whole cache. Eventually we will extract all default versions into a different file and bring them in some other way, but we don't want to introduce a dependency on a build tool like make yet. We're definitely heading in that direction though.

Installed Software

The following is a mostly complete list of the software installed in Dad's Garage. Whatever is already installed in the base image (which is bitnami/minideb:buster) is not listed.

Debian Packages

• build-essential
• ca-certificates
• curl
• dirmngr
• git
• gnupg
• gosu
• jq (docs)
• libaio1
• locales
• openssh-client
• pkg-config
• procps
• python3
• python3-pip
• python3-setuptools
• python3-venv
• unzip

Other

• asdf
• aws-cli
• azure-cli
• k9s
• kubectl
• helm
• nodejs and npm
• pre-commit
• terraform
• terraform-docs
• tflint
• tini

asdf

A lot of the tools are installed using asdf. asdf makes it really easy to use a certain version of a tool. One downside is that since it uses shims you have to reshim if you install other executables. For example, if you pip install foobar you have to then run asdf reshim python for foobar to be found in $PATH.

Contributing

Pull requests are welcome! If you are going to contribute to this project you should

• Have pre-commit installed
• Install the pre-commit hooks by running pre-commit install in this directory
• Run pre-commit run -a if the CI build isn't passing. The CI pipeline runs pre-commit run -a and fails if any of the checks fail.

Dad's Garage CI/CD

Pull Requests are not automatically run through the Codefresh pipeline. A maintainer must put /test in a comment on the PR for the pipeline run to trigger.

Public build logs for Pull Request pipelines can be found here.