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

Publish docker image on DockerHub #51

Open
3 tasks
frosforever opened this issue Oct 1, 2015 · 11 comments
Open
3 tasks

Publish docker image on DockerHub #51

frosforever opened this issue Oct 1, 2015 · 11 comments

Comments

@frosforever
Copy link
Contributor

Leverage DockerHub's Automated build to pick up changes and deploy public saws image to dockerhub.
My understanding is this should be done under @donnemartin's account as he is the owner of saws unless someone else has a better idea on this.

This would require:

@frosforever frosforever changed the title Publish docker container on DockerHub Publish docker image on DockerHub Oct 1, 2015
@donnemartin
Copy link
Owner

@frosforever thanks for looking further into this and for the followup. I'll see if I can add this to DockerHub in the next week or so.

@frosforever
Copy link
Contributor Author

@donnemartin sure thing. If it's any help, I can attempt to run through the steps and publish on my account working out the kinks and then hand over the steps I took. I don't know if there's a better way. It would be cool if one could publish on behalf of a user/repo via docker hub, but I don't know if that's possible.

Also, I realized the current Dockerfile installs via pip and not from the current state of the repo. This might cause a consistency issue with the automated build.

@donnemartin
Copy link
Owner

If it's any help, I can attempt to run through the steps and publish on my account working out the kinks and then hand over the steps I took

@frosforever I think this would be a big help, I've been pretty tied up lately.

Also, I realized the current Dockerfile installs via pip and not from the current state of the repo. This might cause a consistency issue with the automated build.

Hmm interesting catch.

Thanks for your previous contribution, I released it to GitHub and PyPI today and of course credited you :)

https://github.com/donnemartin/saws/releases/tag/0.3.2
https://pypi.python.org/pypi/saws

@frosforever
Copy link
Contributor Author

@donnemartin it ebbs and flows. I'm currently a bit swamped as well but I'll try and get on this sometime.

@donnemartin
Copy link
Owner

@frosforever no rush!

@sysadmiral
Copy link

This would be super useful.

Not sure if this helps or not but codeclimate do something similar with a wrapper script for the docker process (although that's a ruby app):

https://github.com/codeclimate/codeclimate

@sysadmiral
Copy link

sysadmiral commented May 20, 2016

FWIW I have published my image to the docker hub: https://hub.docker.com/r/sysadmiral/saws/

A few things to note:

  • I based the image on alpine cos everyone loves small images right? 😄
  • Just running apk add python && pip install saws on alpine:latest doesn't work - the SAWS "shell" exits immediately because of a segmentation fault
  • To get around this I used python3 and that seems to sort the issue
  • I used apk packages instead of the methods in the official python3:alpine Dockerfile as it felt simpler than what they do
  • Currently I have a separate ~/.saws/creds/ dir with a dir per profile and in each folder I have a config file with my AWS creds/region/output
    • TODO - I will be writing a wrapper to call the container and extract profiles/creds from existing aws/config or aws/credentials so that you can saws-wrapper someprofile and it would run the container with someprofile

Please let me know what you think! If you think the Dockerfile is suitable I can create a PR to update the official one in this repo so that the one on docker hub can be from the official SAWS source?

@donnemartin
Copy link
Owner

@sysadmiral thanks for the help on docker support!

Please let me know what you think! If you think the Dockerfile is suitable I can create a PR to update the official one in this repo so that the one on docker hub can be from the official SAWS source?

I'm not really a docker user myself so I'm not sure I'm the best person to comment.

Perhaps our other docker users (@frosforever @cliveza @stilvoid) might share their thoughts :)

@frosforever
Copy link
Contributor Author

frosforever commented May 24, 2016

Wow, I completely forgot about this!

@sysadmiral Thanks for bringing this up. A few things as I see it:

  • Absolutely agree with alpine!
  • There's value in using the official python docker images. Possibly more consistent updates, battle hardened by having more users etc
  • If this is to move towards an automated build, then it should probably not download from pip but should rather build from the repo sources itself. Eliminating one more moving part. Admittedly, I'm not entirely convinced on this point. I don't do enough python development and deployment to know if that's an issue.
  • Regarding credentials, I'm not sure I follow the script wrapper. Do the methods outlined in https://github.com/donnemartin/saws/blob/master/INSTALLATION.md#docker-installation via credential path or env vars not work?

I've submitted #84 that uses the official python alpine image and builds from sources instead of installing from pip should it be decided that that's the way to go. I've also set up an automated build https://hub.docker.com/r/frosforever/saws/

@sysadmiral What do you think? It seems that your image is a bit smaller (104.8MB vs 97.91MB) but that might just be splitting hairs.

@sysadmiral
Copy link

sysadmiral commented May 24, 2016

Glad I got this moving! 😄

@frosforever just to expand on some of my decisions/your points:

  • I think my smaller image size is related to not using the official python docker image as they install a lot of extra packages to build python itself without any clean up afterwards
    • I "ummed and ahhed" for quite a while on this and in the end the basis for not using the python image was the same reason for using alpine - to keep the image size as small as possible. I am still undecided on which approach is correct.
    • I agree that regular updates and hardening are important but I think this "requirement" would be satisfied by the fact that we are using official alpine packages - they are already doing the updates and security testing for us.
    • as I say I am not sure which is better:
      • using the official python image
      • using an image that uses the official alpine python packages
      • it's a chicken 🐔 and egg 🥚 conundrum!
  • with the credentials I haven't sat down to look at how to pass them through to the container yet so the simplest way I could find to get the container up and running was to have a separate file per profile and specify that file in the docker run command. It's ugly but it works.
    • version 2 will use a wrapper (that can be added to /usr/local/bin/ or such) that will do this automagically. I just need time to work that out.
  • I couldn't comment on building saws from source instead of using the pip package as like you I am not familiar enough with python development and packaging to decide. I guess @donnemartin could decide best approach or provide guidance here based on how quickly the pip package is updated when SAWS source is updated?

I will check out PR #84 later this evening (GMT).

@donnemartin
Copy link
Owner

I couldn't comment on building saws from source instead of using the pip package...

You can install the latest from GitHub source which can contain changes not yet pushed to PyPI:

$ pip install git+https://github.com/donnemartin/saws.git

I haven't refreshed the version on PyPI in awhile (5 months and 35 commits behind), although I plan to do so soon. Pushing to PyPI is more involved than pushing to master :)

I think installing from source is probably a better option if you always want the latest changes.

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

No branches or pull requests

3 participants