Docker with slow rural copper
 

Beginner, trying to learn.
Reading about Docker and frameworks in general.

On very slow rural copper.

Does Docker require/use/need internet good speed at every rebuild/change and other container actions?

Perhaps just install a LEMP stack in one hit and practice on that .... but have been advised to learn within a framework.

I have used a basic WAMP local server for practice on Windows ... and that remains local ... Uniserver Zero.

Waiting to get to a friends broadband to complete a Gecko Static install on this machine so that I can try out some tutorials ... but everything hangs on being able to do this on a very slow connection.

EDIT:
Ending this post question as further reading has made me realise that Docker is not going to help my specific project. Going the simpler (yes, I can hear the laughter) route of a basic LAMP stack on Gecko Static and working from there.
Over and out.
Paul

Just taking this out of zero reply status.
You also might want to mark it SOLVED now.
FWIW, "slow rural copper" really gave me pause, and I had to read the whole post before I understood what you mean.

Solved
 

Thank you - ondoho.
So perhaps it my chance to fork the Linux core and call it "SlowRuralCopper" with an option to upgrade to "FastUrbanGlass ?

Will be returning to the old fashioned LAMP/WAMP with perhaps a bit of Twig in the beginning and then learn some Ajax and javescript.
And can do it all with my "copper" OS.
Paul

Fortunately, many years ago our "rural" telephone company replaced their entire infrastructure with optical. They dotted the landscape with little boxes which connect to the "legacy copper wires," abandoning the old copper trunk-main system (and recycling the stuff for a profit). Gradually now they are offering true optical feeds to those "little boxes." Telephone companies are now offering excellent phone, internet, and video service ... allowing all of us to tell the "Cable" companies to go to hell. :D

I'll tell ya – it's very nice, when something goes wrong with your service, that the folks who are going to fix it live in the next town.

I keep a squid http proxy docker on my server. This way I only have to download updates technically once regardless of how many machines. Is nice. I'm on a 2u/20d fixed wireless isp. I'll take whatever acceleration I can get.

*EDIT* I personally think this should be considered best practices if one is capable. I don't know enough to say anything about bandwidth limits or if it's artifically capped. At the end of the day anything we can take off the main trunks load helps other's do whatever. That's another good reason, if only minor.

"Docker," and containerization in general, really has nothing to do with network speeds at all. By far the easiest way to learn about this stuff is to do it on your own machine.

"Containerization," at its core and no matter exactly how it is done, is basically an illusion. A process that is actually running directly on the host machine is "wearing rose-colored glasses" so that it perceives only what you want it to see – file systems, networks, memory size and so on – all of which has nothing to do with how the host actually is set up. The benefit is that this "smoke and mirrors" work can be done very cheaply, unlike other alternatives for process isolation such as virtual machines. The "containerized" process really is running directly on [some ...] host [somewhere ...], and with minimal additional overhead.

Hosts can run many container (definitions ...) at the same time, knowing that each one will not interfere with any other. They can launch new ones and tear down existing ones instantly. This has spawned an entire industry featuring very profitable players like RackSpace, who can support (and thus, sell to ...) vastly more players at the same time than VMWare hosts can.

All of which really has nothing at all to do with copper or glass.