Removes yakkety support, removes old raspbian repo

[seemethere]

Rasbpian repo has been updated to 17.09.0-ce which includes a fix for
docker service calls on arm architecture, hence the removal of the old
apt repo for raspbian.

Also yakkety is no longer supported in the Docker CE releases so it is
effectively removed from the install script support

Signed-off-by: Eli Uriegas eli.uriegas@docker.com

[seemethere]

cc @alexellis @StefanScherer

[seemethere]

NOTE: Currently investigating the issue with raspbian/stretch, it may require a change more upstream.

[StefanScherer]

@seemethere Thank you. 💯 It works on Raspbian Jessie (HypriotOS).

[thaJeztah]

LGTM, thanks (and thanks for testing @StefanScherer )

[StefanScherer]

Successfully tested an update from 17.05.0-ce (installed with current get.docker.com script) to 17.09.0-ce with this script.

[thaJeztah]

ping @andrewhsu

[alexellis]

I would want to know this works fully with existing images built prior to the requirements for multi-arch only. There was discussion with @StefanScherer on Slack about this.

I'd worry that we'd upgrade and suddenly none of the containers which worked on 17.05 would be able to be scheduled on 17.x in a Swarm.

[StefanScherer]

I've updated our PiCloud cluster to 17.09.0-ce today and I'm able to create services that are spread over three platforms (RPi with 32bit HypriotOS, RPi with 64bit HypriotOS, UP Board amd64).
But I'm always using multi-arch images stored in a private registry ("on-prem" on one of the nodes) for the demos.

The update went fine with this script from 17.05.0-ce (from a previous get.docker.com installation) to 17.09.0-ce.

For the 64bit ARM running a Debian Stretch I had to choose the Ubuntu Xenial DEB package as there is no Debian for arm64 at download.docker.com. Seems like I need docker/docker-ce-packaging#35 😄

[andrewhsu]

If this is working for you @StefanScherer then we'll schedule to bring the changes for this PR to test.docker.com for 17.10.0 ce rc2. And when 17.10.0 GA then the changes of this PR will be brought to get.docker.com.

[StefanScherer]

@andrewhsu I did some further tests and I think we should go further as it looks good to me:

Creating a service in swarm mode works for images that are built on ARM machines.

works:

$ docker service create --name whoami -p 8080:8080 stefanscherer/whoami:rpi
$ docker manifest inspect -v stefanscherer/whoami:rpi | jq .Platform
{
  "architecture": "arm",
  "os": "linux"
}

doesn't work:

docker service create --name whoami -p 8080:8080 stefanscherer/whoami:linux-arm-1.4.1
$ docker manifest inspect -v stefanscherer/whoami:linux-arm-1.4.1 | jq .Platform
{
  "architecture": "amd64",
  "os": "linux"
}

This image is built on Travis (amd64) with a "FROM scratch -> COPY static go binary" docker build.
So this image has "amd64" as architecture.
I'm fine with this behaviour.
If you annotate such an image in a manifest list to be an "arm" image which is done for

works (as normal container):

$ docker run -d -p 8080:8080  stefanscherer/whoami:linux-arm-1.4.1

These cross compiled images can be used for normal docker-compose purposes and docker run.

also works (with a manifest list):

$ docker service create --name whoami -p 8080:8080 stefanscherer/whoami
$ docker manifest inspect -v stefanscherer/whoami | jq '.[].Platform'
{
  "architecture": "amd64",
  "os": "linux"
}
{
  "architecture": "arm",
  "os": "linux"
}
{
  "architecture": "arm64",
  "os": "linux"
}
{
  "architecture": "amd64",
  "os": "windows"
}

@alexellis WDYT?

[seemethere]

The issues experienced in the tests here should be remedied when 17.10.0-ce-rc2 drops with the inclusion of this commit: docker-archive/docker-ce#263

[seemethere]

Updating test.docker.com with these updates

[justincormack]

This PR removed the GPG key checking, how did this not get reviewed?

[seemethere]

@justincormack the gpg key is actually hosted on download.docker.com so it wasn't necessary to have it in the script anymore.

[justincormack]

You do not remove security features with no comment in an unrelated commit. It is more secure to have the key in this file, in case you mirror it, or mirror the distro, and then have more assurance. Otherwise anyone who can compromise the repo can just swap out the key.