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

Support for specifying version & type of MongoDB binary at docker builtime #185

Merged
merged 1 commit into from Jun 16, 2017

Conversation

Projects
None yet
2 participants
@pkdone
Contributor

pkdone commented Jun 12, 2017

I'd like to have the ability to provide docker buildtime overrides for versions of MongoDB generally, most critically allowing the user to choose to build an image based on MongoDB Enterprise version, rather than MongoDB Community version. See suggested and tested changes for 3.4 Dockerfile. I have not attempted to make changes to Dockerfiles of previous version (eg. 3.0, 3.2)

Once these changes are incorporated, this means users can pull down the "official" Mongo github project and build an image like:
$ docker build --build-arg MONGO_PACKAGE=mongodb-enterprise --build-arg MONGO_REPO=repo.mongodb.com .

..to produce a local Docker image that was built using MongoDB Enterprise, rather than the Community version (e.g. for paying MongoDB customers that want to leverage LDAP, Auditing and other advanced security features, but still leverage Docker and its "official" MongoDB project).

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jun 12, 2017

Member

Would it make sense to include pre-built tags for the enterprise editions as explicit variants to make it even easier for users to consume them? (are there licensing concerns with doing that?)

For example, mongo:3.4-enterprise, etc? (see the couchbase tags for an example of another official image doing something similar)

Member

tianon commented Jun 12, 2017

Would it make sense to include pre-built tags for the enterprise editions as explicit variants to make it even easier for users to consume them? (are there licensing concerns with doing that?)

For example, mongo:3.4-enterprise, etc? (see the couchbase tags for an example of another official image doing something similar)

@pkdone

This comment has been minimized.

Show comment
Hide comment
@pkdone

pkdone Jun 12, 2017

Contributor

Technically it absolutely would make sense. However, from a legal perspective I couldn't say whether this would be possible or not (i.e. re-distributing closed source software inside an image). How did the Couchbase repo people solve this?

My current pull request avoids this issue as it's down to the user to build their own image, using the Dokerfile, and it's for them to ensure they are appropriately licensed (the github project contains no binaries, regardless of whether they are open or closed source). Obviously for usability it would be much nicer to have the pre-built images.

Contributor

pkdone commented Jun 12, 2017

Technically it absolutely would make sense. However, from a legal perspective I couldn't say whether this would be possible or not (i.e. re-distributing closed source software inside an image). How did the Couchbase repo people solve this?

My current pull request avoids this issue as it's down to the user to build their own image, using the Dokerfile, and it's for them to ensure they are appropriately licensed (the github project contains no binaries, regardless of whether they are open or closed source). Obviously for usability it would be much nicer to have the pre-built images.

@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jun 12, 2017

Member

They are available publicly via http://repo.mongodb.com without a requiring license acceptance for download, but yeah, redistribution is a bit of a gray area (so without explicit +1 from MongoDB, Inc. I'd not want to do anything "official" with enterprise editions, but figured it was worth asking 😇).

I'm OK with what this is accomplishing, but I would like to cut down on the number of ARGs if we can. Also, all those ENV lines can be smashed together, and this will require updates to update.sh for version bumping (to look for ARG MONGO_xxx rather than ENV).

For example, I think we can should probably leave MONGO_MAJOR hard-coded as an ENV, especially since we've got a directory per MAJOR already (so if a user wants a different major, they should switch directories).

Member

tianon commented Jun 12, 2017

They are available publicly via http://repo.mongodb.com without a requiring license acceptance for download, but yeah, redistribution is a bit of a gray area (so without explicit +1 from MongoDB, Inc. I'd not want to do anything "official" with enterprise editions, but figured it was worth asking 😇).

I'm OK with what this is accomplishing, but I would like to cut down on the number of ARGs if we can. Also, all those ENV lines can be smashed together, and this will require updates to update.sh for version bumping (to look for ARG MONGO_xxx rather than ENV).

For example, I think we can should probably leave MONGO_MAJOR hard-coded as an ENV, especially since we've got a directory per MAJOR already (so if a user wants a different major, they should switch directories).

@pkdone

This comment has been minimized.

Show comment
Hide comment
@pkdone

pkdone Jun 13, 2017

Contributor

Thanks, I'll have a crack at reducing complexity, mirroring for 3.0 & 3.2 and also update.sh changed and come back to in next day or so.

Contributor

pkdone commented Jun 13, 2017

Thanks, I'll have a crack at reducing complexity, mirroring for 3.0 & 3.2 and also update.sh changed and come back to in next day or so.

@pkdone

This comment has been minimized.

Show comment
Hide comment
@pkdone

pkdone Jun 13, 2017

Contributor

OK, changed Dockerfiles for 3.0, 3.2, 3.4 & 3.5 and modified "update.sh" accordingly, and then tested. Now ready for review, thanks.

Contributor

pkdone commented Jun 13, 2017

OK, changed Dockerfiles for 3.0, 3.2, 3.4 & 3.5 and modified "update.sh" accordingly, and then tested. Now ready for review, thanks.

Add ability to provide docker buildtime overrides for versions of Mon…
…goDB generally, most critically allowing the user to choose to build an image based on MongoDB Enterprise version, rather than MongoDB Community version.
@tianon

tianon approved these changes Jun 16, 2017

Thanks! 👍

@tianon tianon merged commit 04fcfb1 into docker-library:master Jun 16, 2017

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Jun 16, 2017

Member

Maybe at some point we can figure out the licensing/redistribution details and mongo:3.4-enterprise (etc) can just exist officially! 😄

Member

tianon commented Jun 16, 2017

Maybe at some point we can figure out the licensing/redistribution details and mongo:3.4-enterprise (etc) can just exist officially! 😄

@pkdone

This comment has been minimized.

Show comment
Hide comment
@pkdone

pkdone Jun 17, 2017

Contributor

Many thanks for merging + lets discuss ent packaging offline. 😄

Contributor

pkdone commented Jun 17, 2017

Many thanks for merging + lets discuss ent packaging offline. 😄

@pkdone pkdone deleted the pkdone:mongo_pkg_and_args_34 branch Jun 17, 2017

@tianon tianon referenced this pull request Dec 19, 2017

Closed

In Memory Support #224

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment