Doubt in creating a development environment with docker plus elixir and phoenix

I spun up a side project with Docker last fall and wrote about it, this post might help.

I know it’s a silly question, but if I follow this post, it will work on Linux.

Personally if you are on Linux(Unix) and have the right permissions why bother with docker?

Installing whole setup would be 3 or so commands, and you can work on the fastest easiest environment to learn, debug

I can’t say with 100% certainty, but yes, I believe that what I wrote will work with Linux

yes, I understand that point of view, but I see that using docker would increase the versatility in the installation in other operating systems, besides I don’t worry if I have to format my computer.

I gave the docker build but this error came on the screen:
db uses an image, skipping
Building web
Step 1/9 : FROM bitwalker/alpine-elixir-phoenix:1.10.3
"# Executing 1 build trigger
—> Using cache
—> cc1de04a9ee9
Step 2/9 : RUN mkdir /app
—> Using cache
—> 70f87955bcb2
Step 3/9 : WORKDIR /app
—> Using cache
—> f721dd85a6ef
Step 4/9 : COPY mix.exs mix.lock ./
ERROR: Service ‘web’ failed to build: COPY failed: file not found in build context or excluded by .dockerignore: stat mix.exs: file does not exist

You can develop locally and use docker just to publish. I don’t get the craze personally.

from my point of view the less time I spend on the environment the more time I can spend on the code, learning, feature sets. Personal preferences.

I have been working on a full featured example container build for Elixir/Phoenix:

It includes support for Visual Studio Code building in a container, as well as:

• Uses Docker BuildKit for parallel multistage builds and caching of OS files and language packages. Multistage builds compile dependencies separately from app code, speeding rebuilds and reducing final image size. Caching of packages reduces size of container layers and allows sharing of data betwen container targets.
• Supports Alpine and Debian, using hexpm/elixir base images.
• Uses Erlang releases for the final image, resulting in an image size of less than 20MB (5.6 MB Alpine OS files, 1.3 MB TLS libraries, 12 MB Erlang VM + app).
• Supports mirroring base images from Docker Hub to AWS ECR to avoid rate limits and ensure consistent builds.
• Supports building for multiple architectures, e.g. AWS Gravaton ARM processor. Arm builds work on Intel with both Mac hardware and Linux (CodeBuild), and should work the other direction on Apple Silicon.
• Supports deploying to AWS ECS using CodeBuild, CodeDeploy Blue/Green deployment, and AWS Parameter Store for configuration. See ecs/buildspec.yml. Terraform is used to set up the environment, see GitHub - cogini/multi-env-deploy: Complete example of deploying complex web apps to AWS using Terraform, Ansible, and Packer · GitHub
• Supports compiling assets such as JS/CSS within the container, then exporting them to the Docker host so that they can be uploaded to a CDN.
• Supports building with docker buildx bake, a docker-native build tool similar to docker-compose which uses the more powerful HCL syntax and supports native caching functionality.
• Supports building with Earthly, an improved Dockerfile with better syntax, caching, and testing workflows.