Now I am going to move into the realm of areas that I consider fun.
What sort of trickery can I use containers for so that I can avoid installing 'stuff' on my development workstation?
Here is my scenario: I am pulling some source from GitHub. I might modify some scripts and need to test those. I want to quickly test my changes within an installed and running instance of the application. I don't want to 'install' the application on my workstation.
So, lets work thorough my real life example. No modifications, just pulling the source and getting that into a container, without any need to build a custom container nor image.
Docker allows you to expose paths of the container host and map those into specific paths of the VM. And this is where you can do some nifty things.
Say that you have some Node.js application. And you want to run multiple instances of it, or you want to run and instance and have the logs write back to your development station.
(This could be any number of combinations).
Lets run through an example:
Previously I ended with the example:
sudo docker run -i -t --name meshblu node:latest /bin/bash
If I extend that with this scenario we will see some new options.
sudo docker start -i -t -v "/home/brianeh/GitHub":"/home":ro --name meshblu node:latest /bin/bash
What I have added is the "-v" option. this defines a path mapping.
"/home/brianeh/GitHub" is the GitHub folder of my user home path. After the colon is the path in the container that this is mapped to. "ro" means Read Only. Or I could define that as "rw" - Read Write.
the neat thing is that once I run my container and enter its console I can type ls -l /home and I will see all of the files I have downloaded to my GitHub folder of my development machine.
This gives me a runspace within the container that is separate from my workstation where I can install applications but run the latest version of my code straight out of the development path.
(One reason why developers love containers)
No comments:
Post a Comment