Łukasz Lach, Docker Captain | 2020
https://lach.dev/ | https://github.com/lukaszlach/
Docker Workshop | http://dockerworkshop.pl/
# This is only used for development. The production will use AWS RDS | |
FROM mysql:5.7.23 as prep | |
# Copy your anonymized files | |
COPY *.anon.sql /docker-entrypoint-initdb.d/ | |
# zz.grant-all-to-sample-user.sql script that to change the permissions on the anonymized data in case it is not owned by the test user | |
# grant all on *.* TO 'sampleuser'@'%'; |
Łukasz Lach, Docker Captain | 2020
https://lach.dev/ | https://github.com/lukaszlach/
Docker Workshop | http://dockerworkshop.pl/
Mute these words in your settings here: https://twitter.com/settings/muted_keywords | |
ActivityTweet | |
generic_activity_highlights | |
generic_activity_momentsbreaking | |
RankedOrganicTweet | |
suggest_activity | |
suggest_activity_feed | |
suggest_activity_highlights | |
suggest_activity_tweet |
docker-machine create --driver hyperv --hyperv-virtual-switch ExternalSwitch registry
docker-machine ssh registry docker run -d -p 5000:5000 --restart=always --name registry registry:2
docker-machine ls # get the ip address of the VM, in this case 10.10.10.197
docker-machine create --driver hyperv --hyperv-virtual-switch ExternalSwitch --engine-insecure-registry 10.10.10.197:5000 swarm-1
docker-machine create --driver hyperv --hyperv-virtual-switch ExternalSwitch --engine-insecure-registry 10.10.10.197:5000 swarm-2
docker-machine create --driver hyperv --hyperv-virtual-switch ExternalSwitch --engine-insecure-registry 10.10.10.197:5000 swarm-3
docker-machine ssh swarm-1 docker swarm init # copy the swarm join command to run on each other hose
docker-machine ssh swarm-2 docker swarm join --token SWMTKN-1-mysecrettoken 10.10.10.198:2377
docker-machine ssh swarm-3 docker swarm join --token SWMTKN-1-mysecrettoken 10.10.10.198:2377
This will get you routable containers with IPs on your existing subnets, advertising to Consul. They will also be scalable and placed across a cluster of Swarm hosts. It's assumed that you are already running Consul, so if not, there are a ton of tutorials out there. It's also assumed you know how to install Docker and various Linux kernels.
Bonus: We add an autoscaling API called Orbiter (https://gianarb.it/blog/orbiter-the-swarm-autoscaler-moves).
So you have an existing environment. You use Consul for service discovery. Life is good. Containers are now a thing and you want to work them in without having to worry about overlay networking or reverse proxies. You also don't want to add extra latency (as some naysayers could use it as fuel to kill your hopes and dreams). Lastly, you don't have a lot of time to invest in a complex orchestration tool, such a
Just run this from your Mac terminal and it'll drop you in a container with full permissions on the Docker VM. This also works for Docker for Windows for getting in Moby Linux VM (doesn't work for Windows Containers).
docker run -it --rm --privileged --pid=host justincormack/nsenter1
more info: https://github.com/justincormack/nsenter1
I have been an aggressive Kubernetes evangelist over the last few years. It has been the hammer with which I have approached almost all my deployments, and the one tool I have mentioned (shoved down clients throats) in almost all my foremost communications with clients, and it was my go to choice when I was mocking my first startup (saharacluster.com).
A few weeks ago Docker 1.13 was released and I was tasked with replicating a client's Kubernetes deployment on Swarm, more specifically testing running compose on Swarm.
And it was a dream!
All our apps were already dockerised and all I had to do was make a few modificatons to an existing compose file that I had used for testing before prior said deployment on Kubernetes.
And, with the ease with which I was able to expose our endpoints, manage volumes, handle networking, deploy and tear down the setup. I in all honesty see no reason to not use Swarm. No mission-critical feature, or incredibly convenient really nice to have feature in Kubernetes that I'm go
# problem: when presenting, I want to obscure | |
# my prompt to act like it's at root of file system | |
# and be very basic with no git info, etc. | |
# solution: this theme lets you set a ENV to the path | |
# of your presentation, which will help remove unneeded prompt | |
# features while in that path | |
# oh-my-zsh theme for presenting demos | |
# based off the default rubbyrussell theme |
This is how to connect to another host with your docker client, without modifying your local Docker installation or when you don't have a local Docker installation.
First be sure to enable the Docker Remote API on the remote host.
This can easily be done with a container.
For HTTP connection use jarkt/docker-remote-api.