Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

specifying target docker daemon for jibDockerBuild #468

Closed
gintautassulskus opened this issue Jun 28, 2018 · 6 comments
Closed

specifying target docker daemon for jibDockerBuild #468

gintautassulskus opened this issue Jun 28, 2018 · 6 comments
Assignees
Milestone

Comments

@gintautassulskus
Copy link

Section Build to Docker daemon provides an example on how to build and push a docker image to minikube docker daemon:

eval $(minikube docker-env)
gradle jibDockerBuild

Is there a gradle-native way to configure target docker daemon for the jib plugin?
I have multiple minikube instances running at the same time and must use minikube --profile option to retrieve specific minikube's docker-envs.

@gintautassulskus gintautassulskus changed the title specifying gradle jibDockerBuild specifying target docker daemon for jibDockerBuild Jun 28, 2018
@coollog
Copy link
Contributor

coollog commented Jun 28, 2018

Hmm, there isn't a way in Jib to configure the target Docker daemon. jibDockerBuild just uses the docker on your PATH, which reads the environment variables that define the target Docker daemon. Configuring the environment to run docker with is a feature we should probably support.

The options are to

  • Provide configuration for dockerHost, dockerTlsVerify, dockerCertPath, and dockerApiVersion
  • Provide configuration for environment variables in general for docker invocations

@gintautassulskus
Copy link
Author

gintautassulskus commented Jun 29, 2018

At first glance, the variable approach seems a bit neater, but the support for environment variable ingestion is more future-proof and flexible.
Whatever the decision, the end solution should integrate well with the minikube plugin.

I have opened an issue which I believe is somewhat relevant to this one.

@coollog
Copy link
Contributor

coollog commented Jun 29, 2018

Since it might be confusing to have environment on the jib extension (which configures the entire build), we may have the jibDockerBuild task configurable with environment variables, so it would look something like:

tasks.jibDockerBuild.environment 'NAME', 'VALUE'

Similarly, for Maven, only the jib:dockerBuild goal will be configurable with dockerBuildEnvironment.

@gintautassulskus
Copy link
Author

In response to #1173 (comment)

We have a number of multi-project gradle builds that require separate development enviromments. Hence the need for Minikube profiles.

If the following PR gets accepted (GoogleContainerTools/minikube-build-tools-for-java#146), then the push of docker images would look something like:

    jibDockerBuild {
        doLast {
            dockerExecutable = "/usr/local/bin/docker"
            dockerEnvironment = minikube.getDockerEnv(projectID)
        }
    }

Where minikube.getDockerEnv(profileID) retrieves docker ENV configuration from the specified minikube instance and configures the jibDockerBuild task to deploy the image to the very same minikube instance.

This way developers can work on two projects at a time with fully isolated enviroments. For smaller projects, minikube with 2-4GB of ram is more than enough. Considering modern hardware it is feasible to comfortably run at least two such instances at the same time.

@coollog
Copy link
Contributor

coollog commented Nov 9, 2018

Version 0.10.0 has been released with this fixed!

@coollog coollog closed this as completed Nov 9, 2018
@coollog coollog reopened this Nov 9, 2018
@coollog coollog closed this as completed Nov 9, 2018
@chanseokoh
Copy link
Member

Not available for Maven, let's leave this open. I think it's better than creating another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants