We developed a tool called "aliases" that defines docker run as YAML and executes it as a command.
GitHub - k-kinzal/aliases: Resolve dependency on all commands by container
Since aliases uses containers, installing the only docker allows you to execute commands in the same way without depending on the environment.
Get Started
$ 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
$HOME/.aliases/aliases.yaml
/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)"
By executing 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.
Switch the version of the command to execute
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
Aaliases overrides tag of 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 rbenv or nvm anymore.
Combine multiple containers and resolve dependency on commands
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 fromhelmfile, 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
By defining dependencies like this you can executekubectl or helm from helmfile.
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 privileged.
Use with untrustworthy images is not safe.
Execute on CircleCI
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: k-kinzal/aliases@0.2.1
jobs:
aliases:
machine: true
steps:
- checkout
- aliases/install
- aliases/gen
- run: make build
workflows:
version: 2
aliases:
jobs:
- aliases
Please prepare 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 circleci command.。
You only need to define commands that work locally.
We want feedback
Aliases is a newborn baby.
Please give us your feedback for better growth.
Top comments (0)