Skip to content

shedock/shedock

Repository files navigation

shedock

Generate the most ethically optimized Dockerfile 🐳 for your shell scripts!

Important

shedock is under active development and is changing everyday. Please consider Watching the repository for releases to get notified whenever a stable build is out!

Features (a.k.a Goals) ✨

🧳 Minimal & Optimized

Shedock will generate the most ethically minimal Dockerfile for your shell script. This means.

  • Automatically detecting and adding your script & shell dependencies to the final Docker image.
  • Add only the stuff absolutely required to run your script and get rid of unnecessary things which ultimately results in a smaller image size.

ℹ️ You own it

  • Shedock will generate a heavily documented Dockerfile so that you can understand what's going on.
  • This way shedock encourages users to learn and maintain the Dockerfile on their own (we are planning to cover this bridge as well).

🧐 Insights

  • We would be lying to ourselves if we say all edge cases are covered. shedock WILL fail in some weird cases. But we try to figure out what those scenarios are & generate tips for you. So that you can make the best decision until shedock becomes capable of fixing it.
  • This also reduces the need to learn a new tool (except Docker). Everything needed will be present in the Dockerfile generated.

Who is shedock built for?

  • Authors, folks who want to distribute their shell-based apps, or bring a new life to them ☘️. Dockerizing your shell scripts makes them available to EVERYONE!
  • Users, folks who don't like installing random shell scripts from the internet & want a nice controllable isolated environment for them i.e. containers.
  • Folks who want to consider Docker as a delivery format for their shell scripts.

When not to use shedock, or when not to write a Dockerfile for your script?

  • If you are depending on the host machine's resources, like notify-send, xdg-open, or anything UI. In these cases, your scripts are deeply tied to the system you use every day, it's hard to replicate that in a containerized environment.
  • These scripts are still cool, but you should consider shipping them via package managers.

Inspiration

I got inspired by my article which I wrote while writing a Dockerfile for ugit (a shellscript based tool). I learned cool new stuff which then I realized can be materialized into this tool.

Installation

We are not ready for a stable release yet. But you can build from the source. THERE IS NO EXE FILE.

Build from source

Pre-requisites

  1. Docker (running)
  2. Go (>=1.21.3)
  3. The Internet

Export these 2 env variables:

  1. DOCKER_HOST
  2. DOCKER_API_VERSION

Mac

export DOCKER_HOST="unix:///Users/$USER/.docker/run/docker.sock"
export DOCKER_API_VERSION=$(docker version --format '{{.Client.APIVersion}}')

Linux

export DOCKER_HOST="unix:///var/run/docker.sock"
export DOCKER_API_VERSION=$(docker version --format '{{.Client.APIVersion}}')

Build

go build -o shedock main.go
./shedock /path/to/your/script.sh

FAQs

It's 202N, why are we still writing shell scripts? They are fun to write + They work, deal with it.
Docker is not a package manager, why are we using it to package shell scripts? It's built to share your work across different systems. brew is not popular on Linux. Flatpaks and AppImages don't work on Mac, and the new Windows Terminal has its package manager now. How much time do you want to spend just packaging stuff compared to people utilizing your work?
What about other tools like docker-squash & docker-slim?
  • They are great, they have a big community behind them actively building and fixing stuff. Give them a try after using shedock.
  • shedock is built to educate devs, we want folks to know what exactly is required to run their script. Not hiding stuff behind some weird image magic.
Why not build this for all tech stacks, why only shell scripts?
  1. When you are building for everyone, you are building for no one.
  2. The author is biased towards writing and sharing shell scripts 🤓.
  3. The author doesn't have the mental energy to build & test it across 100s of tech stacks.
I don't think you are building this right 🙅🏽
  • Great, we have something in common 🙃. I am figuring out stuff on the go. If you think something can be improved, start a new discussion and leave me some helpful tips.