Monday, 30 October 2017

IBM Cloud Private - Docker, Ubuntu and Volumes

So this week I'm tinkering ( I love that word ) with IBM Cloud Private (ICP), and am planning to install the Community Edition (CE) variant on an Ubuntu VM on my Mac.

This is what I have: -
  • macOS 10.13 High Sierra
  • VMware Fusion 10.0.1
  • Ubuntu 17.10
  • Docker 17.0.6.1-ce
  • IBM Cloud Private 2.1.0
and I'm following the ICP installation from here: -


Having pulled the image: -

sudo docker pull ibmcom/icp-inception:2.1.0

Having previously created a target installation directory: -

sudo mkdir /opt/ibm-cloud-private-ce-2.1.0

and changed to that directory: -

cd /opt/ibm-cloud-private-ce-2.1.0

I then tried to start the image: -

sudo docker run -e LICENSE=accept \
  -v "$(pwd)":/data ibmcom/icp-inception:2.1.0 cp -r cluster /data

However, this didn't appear to do anything :-( 

I then dug further in: -

sudo bash
cd /opt/ibm-cloud-private-ce-2.1.0
docker run -e LICENSE=accept \
  -v "$(pwd)":/data ibmcom/icp-inception:2.1.0 cp -r cluster /data

which returned: -

docker: Error response from daemon: error while creating mount source path '/opt/ibm-cloud-private-ce-2.1.0': mkdir /opt/ibm-cloud-private-ce-2.1.0: read-only file system.

This made no sense, given that I'm effectively running as root :-(

I experimented further: -

docker run -it -v /opt/ibm-cloud-private-ce-2.1.0:/data -e LICENSE=accept ibmcom/icp-inception:2.1.0 /bin/bash

which resulted in much the same: -

docker: Error response from daemon: error while creating mount source path '/opt/ibm-cloud-private-ce-2.1.0': mkdir /opt/ibm-cloud-private-ce-2.1.0: read-only file system.

So, for the record, the switch -v /opt/ibm-cloud-private-ce-2.1.0:/data means that the local OS path ( /opt/ibm-cloud-private-ce-2.1.0 ) is being mapped to the local-to-the-container path ( /data ).

I Googled about a bit: -


which made me wonder whether the problem was with the location, rather than the permissions of the target directory.

I tested this theory: -

mkdir ~/ibm-cloud-private-ce-2.1.0
cd ~/ibm-cloud-private-ce-2.1.0
sudo docker run -e LICENSE=accept \
  -v "$(pwd)":/data ibmcom/icp-inception:2.1.0 cp -r cluster /data

This worked without error, and I was able to confirm that the last part of the command: -

cp -r cluster /data

( which copies data OUT of the container INTO the local filesystem, as mapped using the -v switch )

This is how I validated it: -

pwd

/home/dave/ibm-cloud-private-ce-2.1.0

ls ~/ibm-cloud-private-ce-2.1.0/ -R

/home/dave/ibm-cloud-private-ce-2.1.0/:
cluster

/home/dave/ibm-cloud-private-ce-2.1.0/cluster:
config.yaml  hosts  misc  ssh_key

/home/dave/ibm-cloud-private-ce-2.1.0/cluster/misc:
ldap  storage_class

/home/dave/ibm-cloud-private-ce-2.1.0/cluster/misc/ldap:
cacert  keystone.ldap.conf

/home/dave/ibm-cloud-private-ce-2.1.0/cluster/misc/ldap/cacert:

/home/dave/ibm-cloud-private-ce-2.1.0/cluster/misc/storage_class:

So, the moral of the story appears to be that, for Docker on Ubuntu, it's not possible to map volumes from a container to a directory that's NOT in the user's home directory.

I'll dig further …..

Meantime, I can now continue with my ICP implementation ...

For the record, here's how I checked the versions on the Ubuntu VM: -

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful


docker images

ibmcom/icp-inception   2.1.0               fa65473d72d8        7 days ago          445 MB

docker version

Client:
 Version:      1.13.1
 API version:  1.26
 Go version:   go1.8.3
 Git commit:   092cba3
 Built:        Thu Oct 12 22:34:44 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.1-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   5ff8f9c
 Built:        Fri Aug 18 14:48:14 2017
 OS/Arch:      linux/amd64
 Experimental: false

No comments:

Yay, VMware Fusion and macOS Big Sur - no longer "NAT good friends" - forgive the double negative and the terrible pun ...

After macOS 11 Big Sur was released in 2020, VMware updated their Fusion product to v12 and, sadly, managed to break Network Address Trans...