Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
You're right that Docker isn't a VM for regular use. Think of docker like this:
- create an environment that has what is needed to run a specific application
- save that a base image
- build a docker file that builds your application in one "step"
- copy the files in in the last "step"
- sprinkle in any external configuration you may need per build/environment/etc
- set an entrypoint or cmd to run the application you just built.
Then you just run the container and you have a running application with a consistent "platform" for it's execution.
In development, it's common to use the base image + a volume to do local builds into the volume target to test items closer to real time.
Docker compose, swarm, k8s etc can also be used to run integrated test suites as you build. -
You are using it correctly. However docker is not meant to work right away. It's beauty is that you only have to curse your way through to make it work once. When you do - you know all the steps that are required to make it work again. You write those steps in a dockerfile et voila -- you can reproduce a working setup however many times you want! Not only that -- you know exactly what that setup is, since all (well actually most of the) env requirements are in the dockerfile.
-
@SortOfTested Still few questions:
- What if my development environment can be set up in "one step"?
- What if I don't want to only build my source, but also execute it on the container?
Let's suppose I have a Windows PC, I want to build and execute my code on a Linux environment, is Docker suitable for this? -
@netikras What if I lost all the commands? The "history" command inside the container only shows the latest ones, but not all of them
-
- it's not meant for replicating your dev environment (though things like remote vscode can enable that). It's meant primarily for being a build target to allow you to have the same unit of work that will execute in production running anywhere.
- the code is built into an image, each run statement in the dockerfile creates a new layer in the immutable file system docker creates. Docker functions a lot a like git in that regard. After you build the image, you produce a container with it using docker run, and your code should execute. Entrypoint sets the instruction for how your code will execute, and can be set either array style, or bash/string style. You can also override all instructions and config using docker run:
docker run -it --rm -v /volume-name:/local-dir-or-socket --entrypoint runtimeexe image-name {any other args that follow your exe instruction}
Tl;Dr multi-stage builds allow you to build the code in one step, and produce the image in the final step. You can then just run the image with the code using docker run. You can't do things like attach and debug, it's not at that level of the dev process.
Re: windows
Docker builds environment specific images, and only runs on Linux. Docker for windows invisibly installs a Linux vm in the background that hosts the docker daemon, same for MacOS. The windows docker CLI talks to it via the api.
You can absolutely write code on windows and run it on Linux. The only issues you'll have are when you're interacting with file I/O and paths, but that's par for that course. -
Regarding making docker files : i have only tried docker once,but my experience was okish and i was able to build a couple of images and deploy to aws . I mainly followed this tutorial https://docker-curriculum.com/. It has got a few nice definitions. Maybe that will help
-
@crisz then save those last ones you still have and go try to recreate the missing ones.
Related Rants
Well... Erm...
Job interview
Is docker even suitable for anything that isn't deployment?
So much time, so much effort, so much trial and error, and I still feel like I don't know what Docker is for.
I had a development VirtualBox machine, which I used just to compile my code and test my application. So I said "why don't I just use Docker? It would be way simpler". Also because that fucking Virtualbox image was like 10GB, and it was slow af.
The VirtualBox machine wasn't created by me, but it was just given to me by a previous developer, so I just had to imagine what I needed and pick up the pieces. In few hours I was ready with my Dockerfile.
So I tried it, and....... obviously it didn't work. I entered inside my container and I tried to manually execute commands in order to see where it breaks, and I tried to fix each of them. They were just the usual Linux dependencies problems, incompatibility among libraries, and so on.
Putting everything in order, I started over again with a virgin Ubuntu image, and I tried to fix every single error that appeared, I typed something like 1 hundred commands just to have my development machine up and running.
Now I have a running container that works, I don't know how to reproduce it with a Dockerfile, and I don't know what I'm supposed to do with it, because I'm afraid that any wrong command could destroy the container and lose all the job I did. I can't even bind folders because start/exec doesn't support bindings, so I've to copy files.
Furthermore, the documentation about start/exec is very limited, and every question on StackOverflow just talks about deployment. So am I wrong? Did I use containers for something that wasn't their main purpose? What am I supposed to do now? I'm lost, I feel so much stupid.
Just tell me what to do or call a psychologist
rant
crazy
help
docker