Running lab with docker-cli and not with Docker Desktop fails to pull config files

[MHillman612]

Due to Docker Desktop going commercial, I can no longer run it on my work provided Mac. Instead, I have to use docker-cli. (Trust me. The constant emails from Docker representatives telling me I am in violation of licensing even though I am using this for educational purposes is getting truly annoying.) I found a great writeup of getting this installed with Homebrew on a Mac. https://dhwaneetbhatt.com/blog/run-docker-without-docker-desktop-on-macos. There are, however, a couple of issues that I am running into when setting up a lab for the Dive Into Ansible training.

First off is the inability to use localhost or 127.0.0.1 as the IP of the lab master. Instead, the hosts file is modified with the IP of the minikube pointing to docker.local. Using http://docker.local:1000, I can connect to the main page, but connecting to any of the terminals tries to go to 127.0.0.1. This should be able to be solved by using a hostname variable to the main container for the system to use. I am currently working on resolving this as it is inconvenient to constantly change the URL in the browser to make this work.

The second issue is the inability to use the ./config files to set the user names and passwords. For some reason I have yet to unravel adequately, it does not pass the config files to the container(s). I am assuming this is due to hyperkit and its use of minikube. Everything in hyperkit is in its own VM. Perhaps the solution is to use the Vagrant method explained on the same link above, but I have yet to try that method.

Do you have any suggestions on how to pass this information through to hyperkit when starting using the docker-cli instead of Docker Desktop?

[spurin]

Hi @MHillman612

Very sorry to hear about the difficulties you're having. Have you tried the online lab version of this?

https://diveinto.com/p/playground

In your case, I recommend you run this and toggle the 'Ephemeral' option in the toolbar.

This way, you can keep your lab environment data persistent as you learn between sessions.

Alternatively, I have a virtualbox machine that is preconfigured with Docker and port forwarding, therefore you can run this and then just connect to the portal as you would anyhow, i.e. http://localhost:1000

The image for this is here - https://www.dropbox.com/s/70fsd29x4l9le62/Dive%20Into%20Ansible.zip?dl=0 and it's just a case of importing it into Virtualbox and starting.

[spurin]

Oh and also, it's possible to change the target that the portal uses in the docker-compose.yaml file. You add the following to the portal section under environment

• LOCALHOST_OVERRIDE=1.2.3.4

All references to localhost would then be replaced in this case to 1.2.3.4

[MHillman612]

The LOCALHOST_OVERRIDE allowed me to get to the subsystems without having to make any modifications. It still does not pass the usernames and passwords, but is at least a step closer. Thanks for the tip!

(Our pesky little rules at the office also prevent us from running VirtualBox due to licensing requirements, so I WILL get this figured out.)

I do run the normal process on my personal computer and everything works great if I don't have all of these limitations. Thanks for an awesome class!

[spurin]

Superb,

Okay so you could use the default usernames and passwords which would be guest/guest and root/root. The images I’ve created make those accounts if the config files do not exist.

You could also switch it to local volumes rather than mounted, this is what I do in the Docker Desktop extension. Have a look at the following -

https://github.com/spurin/diveintoansible-extension/blob/main/docker-compose.yaml

You should take the block that auto creates and populates the config (lines 3-13), you’d also want the depends_on (lines 26-28) for all of the systems.

Then you’d also want to change the volumes so it’s in the format you see here. Lastly, add in lines 183-199.

Let me know how you get on

On 14 Jun 2022, at 22:17, MHillman612 @.***> wrote:

 The LOCALHOST_OVERRIDE allowed me to get to the subsystems without having to make any modifications. It still does not pass the usernames and passwords, but is at least a step closer. Thanks for the tip!

(Our pesky little rules at the office also prevent us from running VirtualBox due to licensing requirements, so I WILL get this figured out.)

I do run the normal process on my personal computer and everything works great if I don't have all of these limitations. Thanks for an awesome class!

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.