Closed timfallmk closed 4 years ago
cc: @salrashid123 should we install at least kubectl
? I think docker credential doesn't help much as we don't expect people to build/push images with docker-in-docker. Same for local builder. Not sure about the others.
@timfallmk thanks for reporting. There's still a way to install the components via apt-get. See step 5 here: https://cloud.google.com/sdk/downloads#apt-get kubectl
has its own apt package you can install directly via apt-get.
@ahmetb thanks for mentioning the install. For the record, I use all three examples you just mentioned, although in order of priority kubectl is the top.
Is it worth "unlocking" the gcloud install so it can be modified inside the container afterwards?
For the record, I use all three examples you just mentioned, although in order of priority kubectl is the top.
Do you push images using the containerized gcloud? How do you do that? Is it by mounting the docker socket?
Is it worth "unlocking" the gcloud install so it can be modified inside the container afterwards?
I don't think we intentionally lock it down, my guess is that when it's installed via apt-get it gets locked down. This probably means you should not unlock it.
We have an alpine-based image flavor too, give that a try. You should be able to install additional components there.
Do you push images using the containerized gcloud? How do you do that? Is it by mounting the docker socket?
Correct, mounting the docker socket and copying the docker daemon allows you to run direct docker commands (we build and push to gcr from here).
I don't think we intentionally lock it down, my guess is that when it's installed via apt-get it gets locked down. This probably means you should not unlock it.
This is also correct. The "lock" comes from gcloud being installed from a package manager. If it's installed via the curl command (or compiled manually), this configuration file is not set to unmodifiable.
As it currently stands, we essentially build our own gcloud
docker image by using the curl install method and adding components manually. I'd love to pull directly from this image though.
Got it thanks for putting it to a perspective.
I just recalled that kubectl
is present in this image:
$ docker run -i -t google/cloud-sdk kubectl version
Client Version: version.Info{Major:"1", Minor:"7", GitVersion:"v1.7.0", GitCommit:"d3ada0119e776222f11ec7945e6d860061339aad", GitTreeState:"clean", BuildDate:"2017-06-29T23:15:59Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"}
It's just not installed "via" gcloud, that's why it's reporting as Not Installed. We have an internal bug tracking this. However, I think it is technically correct to report it as Not Installed if it's not installed via gcloud. For other components that are missing, we'll be adding those. @salrashid123
yes, as @ahmetb stated for kubctl
for the other components, yes, its a bug (its outright not installable by apt- this is a bug, i'll file one internally today).
/# apt-get install docker-credential-gcr container-builder-local emulator-reverse-proxy gcd-emulator
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package docker-credential-gcr
E: Unable to locate package container-builder-local
E: Unable to locate package emulator-reverse-proxy
E: Unable to locate package gcd-emulator
any news?
seems that docker-credential-gcr
still is not installable using apt
Sorry, no updates on the bugs filed for those packages
@ahmetb perhaps we can refactor the image and just use the non-package installer (i.,e just untar somewhere and set $PATH)?
I’m open to anything. As long as we can add to the bin/ dir that it would normally reside, and the version of the docker-credentials-helper is up to compatible with the gcloud, it is fine.
Can you cc me on the internal bug? It should be made available as an apt pkg.
An alternative solution here might be force-overriding the package manager bit to “off” here temporarily and using “gcloud components install” for some components, and then turning it back on.
For those who urgently need to get this running, use an older tag. I'm using 198.0.0-alpine
.
Is there a workaround for the cloud-firestore-emulator
component?
@mickeyreiss I resorted to building my own emulator images: https://hub.docker.com/r/fixl/google-cloud-sdk-emulators
Sorry for the late update. As you know, the core issue is there are no package installers for gcloud
which w're using in the images so far to install the other componetns. THere's no real reason to use the installers here since we've got named version tags for each release..(i.e the apt-
installers dont' provide any benefit in this case)
Interms of what we'd do here is just not use the apt
based installers and just do the install based on the .tar.gz
here
https://cloud.google.com/sdk/docs/quickstart-linux
right after
https://github.com/GoogleCloudPlatform/cloud-sdk-docker/blob/master/Dockerfile#L20
(just like the alpine image):
https://github.com/GoogleCloudPlatform/cloud-sdk-docker/blob/master/alpine/Dockerfile#L15
this would be pretty easy to do, we can get a PR for this going now
the additional components will be live in the next SDK release
Reopen: had to rollback on the PR since some dependencies were missed:
We'll need another PR like 158 but with the additional components highlighted installed via apt
(eg, apt-get install python2.7 openjdk-8-jdk
)
$ apt-cache depends google-cloud-sdk
google-cloud-sdk
Depends: python2.7 <<<<<<<<<<<<<<<<<<<<<
Conflicts: gsutil
Recommends: python-crcmod
Suggests: google-cloud-sdk-app-engine-java
Suggests: google-cloud-sdk-app-engine-python
Suggests: google-cloud-sdk-pubsub-emulator
Suggests: google-cloud-sdk-bigtable-emulator
Suggests: google-cloud-sdk-datastore-emulator
Suggests: kubectl
$ apt-cache depends google-cloud-sdk-app-engine-python
google-cloud-sdk-app-engine-python
Depends: python2.7
Depends: google-cloud-sdk
$ apt-cache depends google-cloud-sdk-app-engine-python-extras
google-cloud-sdk-app-engine-python-extras
Depends: google-cloud-sdk
Depends: google-cloud-sdk-app-engine-python
$ apt-cache depends google-cloud-sdk-app-engine-java
google-cloud-sdk-app-engine-java
Depends: google-cloud-sdk-app-engine-python
|Depends: <openjdk-7-jdk>
Depends: openjdk-8-jdk
$ apt-cache depends google-cloud-sdk-app-engine-go
google-cloud-sdk-app-engine-go
Depends: google-cloud-sdk
Depends: google-cloud-sdk-app-engine-python
$ apt-cache depends google-cloud-sdk-datalab
google-cloud-sdk-datalab
Depends: python2.7
Depends: google-cloud-sdk
$ apt-cache depends google-cloud-sdk-datastore-emulator
google-cloud-sdk-datastore-emulator
Depends: google-cloud-sdk
Depends: openjdk-8-jdk <<<<<<<<<<<<<<<<<<<<<<<
$ apt-cache depends google-cloud-sdk-pubsub-emulator
google-cloud-sdk-pubsub-emulator
Depends: google-cloud-sdk
|Depends: <openjdk-7-jdk>
Depends: openjdk-8-jdk
$ apt-cache depends google-cloud-sdk-bigtable-emulator
google-cloud-sdk-bigtable-emulator
Depends: google-cloud-sdk
$ apt-cache depends google-cloud-sdk-cbt
google-cloud-sdk-cbt
Depends: google-cloud-sdk
@gannett-ggreer
The README now lists what component is installed for each image, ":latest" never had all components installed as not all components were|are packaged as deb packages and :latest is a deb based installation. https://github.com/GoogleCloudPlatform/cloud-sdk-docker#components-installed-in-each-tag
"Is it worth "unlocking" the gcloud install so it can be modified inside the container afterwards?" The install was never locked, but when you install google-cloud-sdk from a deb file the component subsystem is disabled, you need to install other components with apt.
the openjdk 8 issue was fixed by allowing the sid repo, hopefully that can be removed as soon as the pubsub-emulator verifies that it works on Java 11.
The Readme states that all components are installed in the
latest
version of the image (as opposed to theslim
oralpine
versions). Running a fresh image shows that some components are not installed in the image, such askubectl
anddocker-gcr-credential-helper
for example.As expected, components cannot be installed into the container after startup.