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

Enable additional volume mounts and ports by default #16

Conversation

jbarlow-mcafee
Copy link
Contributor

This commit exposes volume mounts by default for the MISP and SSL
cert/key directories.

This commit also exposes ports for external configuration, including the
web server (80 and 443), mysql (3306), redis (6379), and MISP ZeroMQ
(50000).

The purpose of the commit would just be to make it easier for users to
be to see the available ports and volumes at container creation time in
GUI tools like Kitematic or Docker Cloud without having to do any
customization of the Dockerfile or with docker commands on
the command line.

Thanks for considering this!

This commit exposes volume mounts by default for the MISP and SSL
cert/key directories.

This commit also exposes ports for external configuration, including the
web server (80 and 443), mysql (3306), redis (6379), and MISP ZeroMQ
(50000).
@@ -112,6 +113,8 @@ RUN mkdir /var/www/.composer && chown -R www-data:www-data /var/www/.composer ;
sudo -u www-data cp -a /var/www/MISP/app/Config/core.default.php /var/www/MISP/app/Config/core.php ; \
sudo -u www-data cp -a /var/www/MISP/app/Config/config.default.php /var/www/MISP/app/Config/config.php

VOLUME /var/www/MISP/app/Config
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to move this from where it was previously because otherwise the git clone into the /var/www/MISP directory earlier would fail because the directory was non-empty. Maybe there's a better way to do this though?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The only problem here is that per Docker the way volume mounts work is that if you make any changes after declaring them - those changes are lost.

Specifically:

"if any build steps change the data within the volume after it has been declared, those changes will be discarded."

This basically summarizes as having to declare Volumes "up above" before anything actually utilizes them/makes changes to them.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jbarlow-mcafee ^ Just pinging about this in case it was lost among the emails from the pull request/merges/etc.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ventz Ah, sorry. I apparently missed the e-mail notifications for your responses. I agree that the order for the volume mounts would be a problem with the changes as I have them here. I've been working on a separate idea for how these volumes could be mounted by default. As these changes would be more extensive than what I have here, I'll put up a separate PR with those and just close this one out for now. Thanks again!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I put up #17 as a replacement for this PR.

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

Successfully merging this pull request may close these issues.

2 participants