unixPB: Add static Alpine containers for tests

[aahlenst]

I've largely followed #1925. I copy and pasted the CPU/RAM config. Please adjust as you see fit.

The SSH key and the password are baked into the container image (as it's done in #1925). If we want to change that, I'd rather do it for all containers in a separate PR. I did a test run with _sanity.openjdk.

Fixes #1929.

Checklist

• commit message has one of the standard prefixes
• FAQ.md updated if appropriate
• other documentation is changed or added (if applicable)
• playbook changes run through VPC or QPC (if you have access)
• for inventory.yml changes, bastillion/nagios/jenkins updated accordingly

[sxa]

OK with this in principle but jenkins is not successfully interacting with the host:

[02/22/21 16:37:52] [SSH] Starting sftp client.
ERROR: [02/22/21 16:37:52] [SSH] SFTP failed. Copying via SCP.
java.io.IOException: Unexpected end of sftp stream.
	at com.trilead.ssh2.SFTPv3Client.readBytes(SFTPv3Client.java:217)
	at com.trilead.ssh2.SFTPv3Client.receiveMessage(SFTPv3Client.java:240)
	at com.trilead.ssh2.SFTPv3Client.init(SFTPv3Client.java:864)
	at com.trilead.ssh2.SFTPv3Client.<init>(SFTPv3Client.java:108)
	at com.trilead.ssh2.SFTPv3Client.<init>(SFTPv3Client.java:119)
	at com.trilead.ssh2.jenkins.SFTPClient.<init>(SFTPClient.java:43)
	at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:667)
	at hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:113)
	at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:457)
	at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:423)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:823)

[02/22/21 16:37:53] [SSH] Copying latest remoting.jar...
java.io.IOException: Could not copy remoting.jar into '/home/jenkins' on agent
	at hudson.plugins.sshslaves.SSHLauncher.copySlaveJarUsingSCP(SSHLauncher.java:817)
	at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:723)
	at hudson.plugins.sshslaves.SSHLauncher.access$300(SSHLauncher.java:113)
	at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:457)
	at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:423)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:823)
Caused by: java.io.IOException: Error during SCP transfer.

[aahlenst]

@sxa Should be fixed. I checked SSH only, didn't know that scp/sftp would be necessary.

[sxa]

@sxa Should be fixed. I checked SSH only, didn't know that scp/sftp would be necessary.

Interesting - me neither (they're only used to copy stuff into the machine) but adding the client tools seems to have done the track - https://ci.adoptopenjdk.net/computer/test-docker-alpine311-x64-1/ and https://ci.adoptopenjdk.net/computer/test-docker-alpine312-x64-2/ are now online

What was the reason for adding a random password to the account - does Alpine have an issue with an account that doesn't have a password set?

[aahlenst]

What was the reason for adding a random password to the account - does Alpine have an issue with an account that doesn't have a password set?

There's a comment in the Dockerfile. On Alpine, the default configuration prevents SSH logins when the password is empty. It's also not possible to unlock the account without a password. So I thought the quickest option is to create a random password.

[karianna]

Do we need both versions of Alpine?

[sxa]

What was the reason for adding a random password to the account - does Alpine have an issue with an account that doesn't have a password set?

There's a comment in the Dockerfile. On Alpine, the default configuration prevents SSH logins when the password is empty. It's also not possible to unlock the account without a password. So I thought the quickest option is to create a random password.

Yep that's ok - just wanted to verify that it really was something specific to Alpine since we don't do that elsewhere. We could also set it to only allow ssh without-password.

[aahlenst]

Do we need both versions of Alpine?

@karianna Why should we have less coverage? I'd rather add 3.13 or move 3.12 to 3.13 if we cannot have more containers.

[sxa]

Do we need both versions of Alpine?
@karianna Why should we have less coverage? I'd rather add 3.13 or move 3.12 to 3.13 if we cannot have more containers.

Curious - you mention 3.13 here, but you've only created the images for 3.11 and 3.12 - what was the reason for including 3.11 over 3.13? Not critical and I'm ok with approving regardless (and this matches what we've now deployed ;-) ) but would be good to have the reason documented

[sxa]

We've deployed this and the machines are available in jenkins. I'd suggest using startallcontainers on one of them (possibly both) as I want to have the ability at playbook deployment team to restrict how many containersa re deployed on any particular host, but this can go in regardless.

[aahlenst]

Curious - you mention 3.13 here, but you've only created the images for 3.11 and 3.12 - what was the reason for including 3.11 over 3.13?

3.13 came out recently, but my head didn't get the update yet. Should I move it to 3.13 so that we have 3.11 and 3.13? Or do we have enough resources for 3.11, 3.12, and 3.13? Just changing the number in the Dockerfile should be sufficient.

[karianna]

Curious - you mention 3.13 here, but you've only created the images for 3.11 and 3.12 - what was the reason for including 3.11 over 3.13?

3.13 came out recently, but my head didn't get the update yet. Should I move it to 3.13 so that we have 3.11 and 3.13? Or do we have enough resources for 3.11, 3.12, and 3.13? Just changing the number in the Dockerfile should be sufficient.

I'd go 12 and 13 to encourage a more secure baseline?

[aahlenst]

I'd go 12 and 13 to encourage a more secure baseline?

Can you please elaborate on what you mean with "secure" in this context?

[karianna]

I'd go 12 and 13 to encourage a more secure baseline?

Can you please elaborate on what you mean with "secure" in this context?

Haven't dug into it but folks have requested us to go to 13 in the docker repo due to CVE concerns in the base image.

[aahlenst]

Haven't dug into it but folks have requested us to go to 13 in the docker repo due to CVE concerns in the base image.

Can you link the issue? Alpine Linux themselves state that support is provided for 2 years for each release branch. AdoptOpenJDK/openjdk-docker#513 doesn't say anything about security. I went through multiple pages of issues with the word "alpine" and all CVEs referred to needed image updates, not Alpine version bumps, for example AdoptOpenJDK/openjdk-docker#475.

[karianna]

Haven't dug into it but folks have requested us to go to 13 in the docker repo due to CVE concerns in the base image.

Can you link the issue? Alpine Linux themselves state that support is provided for 2 years for each release branch. AdoptOpenJDK/openjdk-docker#513 doesn't say anything about security. I went through multiple pages of issues with the word "alpine" and all CVEs referred to needed image updates, not Alpine version bumps, for example AdoptOpenJDK/openjdk-docker#475.

Yeah, my bad, I think we could support 11, 12, 13 here.

[sxa]

Since this hasn't been flagged as a "changes requested" I'm going to merge this PR (Since it matches what I've deployed) and we can upgrade the version of Alpine if required under a separate PR.