Recreating eefac619f384_eefac619f384_proxy ... error

[mabuhijle]

doing a first time deployment of ADOP, I get this error:

Recreating jenkins-slave Recreating eefac619f384_eefac619f384_proxy ... error

ERROR: for eefac619f384_eefac619f384_proxy Cannot start service proxy: driver failed programming external connectivity on endpoint proxy (f64fc7fecba9214aa620743689722eb97acad5a792f738d288401Recreating ldap-ltb ... done

ERROR: for proxy Cannot start service proxy: driver failed programming external connectivity on endpoint proxy (f64fc7fecba9214aa620743689722eb97acad5a792f738d2884015e2bcc03eb3): Error starting userland proxy: Bind for 0.0.0.0:80: unexpected error Permission denied Encountered errors while bringing up the project.

mohammed.abuhijle@CPX-VE92VDMZI53 MINGW64 ~/adop-docker-compose (master) $

I am running on git bash version <git version 2.14.1.windows.1> with docker version: $ docker version Client: Version: 17.06.2-ce API version: 1.30 Go version: go1.8.3 Git commit: cec0b72 Built: Tue Sep 5 19:57:19 2017 OS/Arch: windows/amd64

Server: Version: 17.06.2-ce API version: 1.30 (minimum version 1.12) Go version: go1.8.3 Git commit: cec0b72 Built: Tue Sep 5 19:59:19 2017 OS/Arch: linux/amd64 Experimental: true

The error occurred upon running this command for the first time: $ ./adop compose init .

[nickdgriffin]

Hello,

It says that it's recreating some of the containers, which implies that ADOP/C has been stood up before on the Engine you are targetting or that you've run the command multiple times.

That aside, it's saying:

Bind for 0.0.0.0:80: unexpected error Permission denied

Which suggests that the Docker Engine isn't running as root or something is already listening on port 80 - can you check please?

Thanks, Nick

[mabuhijle]

Thanks Nick. Yes, I have tried multiple ties before, the reason i said "for the first time" is t indicate a fresh attempt to get ADOP to deploy, my bad.

I cant seem to su as root on git bash as it just hangs but I think the problem has to do with this message from the deployment script;

mohammed.abuhijle@CPX-VE92VDMZI53 MINGW64 ~/adop-docker-compose (master) $ ./adop compose init --without-pull

      ###    ########   #######  ########
     ## ##   ##     ## ##     ## ##     ##
    ##   ##  ##     ## ##     ## ##     ##
   ##     ## ##     ## ##     ## ########
   ######### ##     ## ##     ## ##
   ##     ## ##     ## ##     ## ##
   ##     ## ########   #######  ##

• Initialising ADOP Docker Machine is not available or the default machine does not exist, defaultin g to localhost HINT: Either specify one with 'adop compose -m ', or use 'eval $(docker-ma chine env default)' Sourcing provider-specific environment files... Your secrets file already exists, will not re-create... Sourcing variables from platform.secrets.sh file... The version of your secrets file is up to date, moving on...
• Setting up Docker Network Network already exists: local_network
• Skipping Pulling Docker Images
• Bringing up ADOP... Docker Machine is not available or the default machine does not exist, defaulting to localhost HINT: Either specify one with 'adop compose -m ', or use 'eval $(docker-machine env default)'

So, the fact that it cant find a docker machine, makes it default to the local host on which port 80 is indeed being used.

I already did install a docker machine with version: $ docker-machine.exe version docker-machine.exe version 0.12.2, build 9371605

Trying to Identify the active machine show that there is none; mohammed.abuhijle@CPX-VE92VDMZI53 MINGW64 ~/adop-docker-compose (master) $ docker-machine.exe active No active host found $

so, how do i start a proper docker-machine for ADOP to deploy onto and how do I point to it (env variable to use) ?

does that make sense?

Regards, Mohammed

[nickdgriffin]

Hi Mohammed,

The ADOP CLI that you are using is designed to be used against an already setup Docker Engine, so if you've not taken care of that step that will be why you are seeing this problem. The "quickstart.sh" script on the other hand uses Docker Machine to create either a local virtualbox VM or a remote AWS host and then calls the ADOP CLI against it and is perhaps the option you need.

Kind Regards, Nick