Automated Builds - Need one for each dockerfile/image

[dougbtv]

I think we'll need dockerhub automated builds for each container we're creating... Those will be...

sipcapture/homer-webapp --> ./webapp/.
sipcapture/homer-kamailio --> ./kamailio/.
sipcapture/homer-cron --> ./cron/.

Also needed:

• Change naming in docker-compose.yml to sipcapture/* (was qxip/*)
• Also nice! We should add a README.md file in each directory containing a Dockerfile.

[lmangani]

ACK will get ahead with some of the above

[danjenkins]

++ on this, I just faced the same issue. I just want to download the images from dockerhub and not have to build them myself; in a production type environment I don't want to use docker-compose or clone down git repos just to build images.

[lmangani]

Started working on structure....

Container	Pull
webapp	sipcapture/homer-docker:webapp
cron	sipcapture/homer-docker:cron
kamailio	sipcapture/homer-docker:kamailio
opensips	sipcapture/homer-docker:opensips
everything	sipcapture/homer-docker:latest

[danjenkins]

hey @lmangani , I don't agree that these should be tags on the homer-docker image. Tags are there to pin to versions etc. These should all be separate images and shouldn't have docker in their names. Its not good to have different images under the image name. Plus, what will you do when you want versions of the web app etc?

I propose, same as @dougbtv

sipcapture/homer-webapp
sipcapture/homer-cron
sipcapture/homer-kamailio
sipcapture/homer-opensips
sipcapture/homer-docker (everything) - purely from a keeping things working historically point of view.

[dougbtv]

+1 to Dan's suggestions

On Fri, Sep 23, 2016, 7:28 AM Dan Jenkins [email protected] wrote:

hey @lmangani https://github.com/lmangani , I don't agree that these
should be tags on the homer-docker image. Tags are there to pin to
versions etc. These should all be separate images and shouldn't have docker
in their names.

sipcapture/homer-webapp
sipcapture/homer-cron
sipcapture/homer-kamailio
sipcapture/homer-opensips
sipcapture/homer-docker (everything) - purely from a keeping things
working historically point of view.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
sipcapture/homer-docker#3 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFN_vQimx1PstVHoJxJG6EzrjtuKG4TTks5qs_AkgaJpZM4H38h5
.

[lmangani]

Not to be the party breaker but.... unless I am mistaken, this is only reflected on docker HUB pull style and has nothing to do with the repository structure right? As our containers are only really meant to be executed together and are not general purpose, is it not best to keep them bundled? What are the disadvantages other than aesthetic?

[danjenkins]

So theres homer v5 right now, and I want to pull down v5 forever (I dont want to pull latest because at some point latest = v6 and breaks things)

The correct way to do things is to have the version number as a tag so that I can pull down sipcapture/homer-webapp:5 or sipcapture/homer-webapp:5.1, :5 being I want all changes within 5 and :5.1 being I want all patch changes under .1

You can't do any of that with how you want to use tags. Also, when I think of Homer, I think of the web app, not necessarily everything else, Kamailio is a server that collects info, yes but that could quite easily be a node app that I write next week. You are helping people by giving them a working Kamailio that only does Homer things, so thats great but its not a core part of Homer is it, we could replace Kamailio with OpenSips, and we could replace both of them with something else next week. All of things are separate parts. You can join them all together using Docker-compose (or kubernetes or swarm or whatever) - you shouldnt use image names/tags as a way of doing that.

[lmangani]

Point taken on the versions, not being a heavy docker user I took that as flexible factor - just to close the loop clear, what would the difference be between sipcapture/homer-webapp:5.1 and sipcapture/homer-docker:webapp5.1 other than having multiple repositories to maintain?

EDIT: I appreciate this discussion a lot to improve the usability :)

[danjenkins]

Well the second one goes completely against how docker images are laid out as standard, your grouping is sipcapture, you could make a homer user and push them to that... an image name represents the image, the one thing that image does and so you shouldnt have images with different tags that do different things.

When you say repos, do you mean git repos? You don't need to have multiple git repos at all. Theres no difference in workload between pushing sipcapture/homer-webapp:5.1 and sipcapture/homer-docker:webapp5.1 - you are gaining by following the docker standards and so when newbies come to the project (like me today), you don't make them go "I'm really confused as to whats going on here" - exactly what I did with the homer-docker image as it stands - a container should do one thing and thats it - which led me to this issue

[lmangani]

ACK, will proceed as suggested! Thanks a bunch for the suggestions and guidance guys :)

[lmangani]

Et voila' ready to update the compose et all

Container	Pull
webapp	sipcapture/homer-webapp
cron	sipcapture/homer-cron
kamailio	sipcapture/homer-kamailio
opensips	sipcapture/homer-opensips

[lmangani]

FYI moving builders to https://codefresh.io where there seems to be new (and much, much faster) ways to perform post-build tests... giving it a shot, if anyone wants to join I'll co-op you on the projects. Thanks!

[dougbtv]

Sounds awesome Lorenzo -- I'll check back soon and hopefully change out the k8s pod specs to match the official namespace for the docker images (had used mine own for quickly iterating on rebuilding some images)

[lmangani]

Thanks Doug! Feel free to push all/any changes to the master and let me know If I can get some work off your back in the process. BTW plenty of great mentions of you at both OpenSIPS Summit / KamailioWorld :)

[danjenkins]

👍