We developed a tool called "aliases" that defines
docker run as YAML and executes it as a command.
Since aliases uses containers, installing the only docker allows you to execute commands in the same way without depending on the environment.
$ curl -sSL 'https://github.com/k-kinzal/aliases/releases/download/v0.2.1/darwin-amd64.tar.gz' | tar xvz $ cp aliases /usr/local/bin/aliases
/usr/local/bin/kubectl: image: chatwork/kubectl tag: 1.11.2 env: KUBECONFIG: $KUBECONFIG volume: - $HOME/.kube:/root/.kube - $PWD:/work workdir: /work
Aliases can be used as a command by defining command names, images, and tags, and
docker run options.
$ eval "$(aliases gen --export)"
aliases gen the command will be set to
PATH and made available.
$ kubectl get all
You can execute the command with just this.
The command defined in aliases will work the same in your environment, your colleague's environment, or the CI environment.
You can solve the problem from which the command suffers regarding the installation method as it does not work with the need version.
The kubernetes cluster and the
kubectl command must be the same version.
So, if you have multiple kubernetesk clusters, you will be troubled about how to make the kubernetes cluster and
kubectl versions the same.
Aaliases can do that.
$ kubectl get all # It works with the version defined by aliases.yaml $ KUBECTL_VERSION=1.8.4 kubectl get all # It works with the version by environment variable
aliases.yaml with an environment variable of
[COMMAND NAME] _VERSION.
You can easily switch versions with just this one.
You do not have to think about using version switch mechanisms like
One of the problems when executing a container is that you can not execute a command that not install in the container image.
For example, when using
helmfile you need to install
helm in the same container.
However, when you want to use the
kubectl command and other commands from
helmfile, you have to recreate the container image many times.
In aliases you can resolve dependencies on other commands by defining command dependencies without re-creating container images.
/usr/local/bin/kubectl: image: chatwork/kubectl tag: 1.11.2 env: KUBECONFIG: $KUBECONFIG volume: - $HOME/.kube:/root/.kube - $PWD:/work workdir: /work /usr/local/bin/helm: image: chatwork/helm tag: 2.11.0 volumes: - /tmp:/tmp - $HOME/.helm:/root/.helm - $PWD:/work workdir: /work /usr/local/bin/helmfile: image: chatwork/helmfile tag: 0.40.1-2.11.0-1.11.2 volumes: - /tmp:/tmp - $HOME/.kube:/root/.kube - $HOME/.helm:/root/.helm - $PWD:/work workdir: /work dependencies: - /usr/local/bin/kubectl - /usr/local/bin/helm
dependencies like this you can execute
You no longer need to create your own container image.
You use it if there is a container image that is officially distributed. If you need dependencies on new commands, you can combine them.
However, this feature uses docker
Use with untrustworthy images is not safe.
Environment-independent aliases makes it easy to execute in CI such as CircleCI.
To use it with CircleCI, please use CircleCI Orb provided by aliases.
version: "2.1" orbs: aliases: email@example.com jobs: aliases: machine: true steps: - checkout - aliases/install - aliases/gen - run: make build workflows: version: 2 aliases: jobs: - aliases
aliases.yaml in the project root.
Then you can execute the same command as local without writing command installation.
You no longer need to debug many times with the
You only need to define commands that work locally.
Aliases is a newborn baby.
Please give us your feedback for better growth.