Repository navigation
Provide container image based on Alpine or similar (with shell) #168
Description
Activity
Hey, @ogarcia . The dockerfiles we provide that help you build the binary if
dockeris available in your system butgoisn't are indeed based on alpine. So I'm guessing you are talking about the installation alternative where you aliastxto adocker run ...command. We made a conscious effort to make this image as small as possible so I am hesitant of basing it on alpine instead of scratch. Is it too big of an inconvenience to instead use the binarytxcommand from within an image/container you define in the context of your build?What you can do is to add a new "flavor" (a tag) to the docker image. So that you have an alpine tag that is different from the latest tag:
- transifex/txcli:latest -> From scratch
- transifex/txcli:alpine -> From Alpine
- For versions ->
v1.6.7-alpinev1.6-alpinev1.6-alpineor/andv1.6.7-alpine3.17.3,v1.6-alpine3.17.3,v1-alpine3.17.3
This way you will have both possibilities. The smallest possible image and one that has shell tools.
Many CI/CD systems (e.g. GitLab CI, Drone or CircleCI) rely on starting a container and executing commands in it, for which they need the container itself to provide a shell. It would be very interesting to have a "flavor" of the container based on Alpine Linux or similar.
Personally I prefer Alpine because it takes up the least amount of space with a package manager. Busybox is also a good option, but not having a package manager prevents someone to use the image as a base and easily install dependencies they may need for their project. As for Debian, the problem is that it will fatten the image by at least 80 or 90 Mb.