#docker

/

      • aveferrum
        can you see the ports are exposed with docker ps command?
      • jeffreylevesque
        this is what i just did - https://bpaste.net/show/34d255056c02
      • aveferrum
        and can you check basic connectivity with telnet ?
      • jeffreylevesque
        i just removed "-p 27017:27017"
      • aveferrum
        telnet mongodb 27017
      • jeffreylevesque
        shoot
      • i just destroyed reran my unit-test script, it destroyed everything, and rebuilds
      • aveferrum
        :(
      • Connectivity seems fine as you are able to ping each other
      • jeffreylevesque
        so, i should try ``sudo docker exec -it redis telnet mongodb 27017`?
      • i hope it doesn't tell me that telnet is not installed
      • aveferrum
        I may suggest that mangodb may not actaully listening on 27017
      • excitatory has quit
      • exaroth joined the channel
      • troys joined the channel
      • KoSisMe has quit
      • jeffreylevesque
        27017 is the default port for mongodb
      • before i rebuild, changed it to 37017
      • so, i'll test both when things finish building
      • aveferrum
        you can also check the port mappings with docker ps -a
      • jeffreylevesque
        from the host right?
      • outside of the docker containers
      • aveferrum
        yes.
      • jeffreylevesque
        i tried nmap this morning, and it said nmap wasn't installed
      • aveferrum
        It should show like 0.0.0.0:27017->27017
      • KermitoniT joined the channel
      • jeffreylevesque
        terminal still has some active history when i scrolled up - https://bpaste.net/show/c4dfcb694db7
      • doesn't show any ports
      • i wasn't sure if that means anything, since all the containers are all on the same network
      • a3Dman has quit
      • aveferrum
        yeah. but ports should be exposed
      • geggam has quit
      • f0rks joined the channel
      • jeffreylevesque
        So, i should explicitly `EXPOSE 27017`, in the mongodb.dockerfile?
      • aveferrum
        I guess so
      • That will expose the port..
      • you actually may not need to use -p command
      • jeffreylevesque
        which is what i want?
      • aveferrum
        because you're not connecting from host to a container
      • you want containers to connect each other
      • jeffreylevesque
        well, one small problem, the vagrant host, is my development environment, and has an active mongodb on port 27017
      • which, is why just recently, i attempted for the mongodb instance to bind 0.0.0.0, and use port 37017
      • and, i also removed the -p thing
      • shrenik has quit
      • that pastebin is predicated without -p
      • i just haven't committed code to github to reflect that
      • aveferrum
        Ok. I think EXPOSE 27017 in mongodb.dockerfile will solve the issue
      • jeffreylevesque
        do i need to do `-p 37017:27017` or something, since the host vagrant is alreayd using 27107?
      • ascarter joined the channel
      • m0x90 joined the channel
      • aveferrum
        That's if you want to connect from host to your mangodb container
      • jeffreylevesque
        i'll just change the mongodb container to use 37017, and `EXPOSE 371017` in the mongodb.dockerfile
      • oh yea
      • i will change my mongodb.dockerfile, and kill this build, then restart it
      • larsfronius joined the channel
      • aveferrum
        How about the mangodb service?
      • Will you need to change any config for it to work on 37017?
      • enderandpeter has quit
      • jeffreylevesque
        just a central yaml file
      • it's really convoluted right now, puppet provisions docker (not ideal i guess)
      • venmx joined the channel
      • exaroth joined the channel
      • sz0 has quit
      • the app, and puppet depend on the same yaml file
      • czart__ has quit
      • czart__ joined the channel
      • TooLmaN joined the channel
      • KoSisMe joined the channel
      • ascarter joined the channel
      • a3Dman joined the channel
      • larsfronius has quit
      • aveferrum
        still building?
      • jeffreylevesque
        just restarted it about 3-5 minutes ago
      • i'll kill my other builds to speed this up
      • rebase joined the channel
      • it's going to take about ~15 minutes :(
      • i really should dockerize the unit testing
      • Pavo has quit
      • m0x90_ joined the channel
      • because there's no sense to provision the container with puppet, with the idea of consistency, since puppet can be unit tested anyways
      • it really slows down things
      • aveferrum
        yeah..but keep in mind that when you dependency link the containers that doesn't mean docker will wait for others to be ready
      • iAmerikan has quit
      • a3Dman has quit
      • jeffreylevesque
        i was trying to recycle the development puppet code, for the docker unit testing containers, with time, i had to make tweaks to the puppet environment to provision docker
      • so, my initial idea of consistent puppet code, is out the window already
      • casualjim joined the channel
      • saschpe has quit
      • aveferrum
        are you building locally? or on cloud?
      • jeffreylevesque
        locally
      • on a laptop
      • i have a server here
      • but, i have to build a staging environment
      • saschpe joined the channel
      • this is just a pet project that i work on after, and before work
      • so, it's take forever to get anything done
      • aveferrum
        it looks nice :)
      • jeffreylevesque
        thanks
      • i have another repo privately
      • and i'm building hardening scripts, to secure a ubuntu environment
      • when that's done, i will migrate a server
      • *to a server
      • a3Dman joined the channel
      • Rodya_ joined the channel
      • mischat joined the channel
      • venmx has quit
      • Peleus has quit
      • zerocoolback joined the channel
      • quazimodo joined the channel
      • larsfronius joined the channel
      • fassl_ joined the channel
      • Casper_v2 has quit
      • pwnz0r joined the channel
      • Casper_v2 joined the channel
      • daMaestro joined the channel
      • larsfronius has quit
      • pwnz0r
        hello, new docker user here.. I am trying to install a legacy RPM into a centos:latest image. I am hitting the issue where I want to run my rpms dependencies in their own respective containers. I suspect this is a common problem.. Do I need to repackage the rpm basically or is ther any way around this
      • .. and the issue of course is that yum/dnf/apt-get what have you will want to install the deps with the package
      • sebumd has quit
      • daMaestro
        use a subpackage is a common technique
      • agc93
        pwnz0r: RPM doesn't know about containers and as far as it is concerned, each container is it's own host (since they effectively are), so yes, it will just install the package into your container the same way it would install it on any other platform
      • pwnz0r
        daMaestro: thats a good idea indeed
      • daMaestro
        pwnz0r, which, yes, requires you to rebuild the package. it's a way to bifurcate the dependencies of different parts of the app have different deps
      • pwnz0r
        right you just fragment and the final rpm will dep on all the frags
      • and then the subpackages can be easily dockerified
      • daMaestro
        pwnz0r, well.. sorta. it's a way to have multiple related packages from one source rpm
      • pwnz0r
        o you mean like have more than one spec and just exclude the deps basically?
      • daMaestro
      • pwnz0r, each subpackage is able to define their own deps
      • pwnz0r, i'll just ASSuME you are doing something like myapp-server, myapp-client and you might have myapp-libs/common/something that both need
      • pwnz0r
        ok cool this looks promising! thanks
      • ya pretty much
      • daMaestro
        pwnz0r, so then you'd install myapp-server in the container you want to run the server (which will pull in all deps to run the *server*), and then install myapp-client in the other container and it will bring in all it's specific deps
      • pwnz0r, very common practice and the link i gave you has references to more details
      • pwnz0r
        ok cool
      • one example that doesnt really fall under that is the when myapp-server deps on a db
      • thats where i really want to remove that dep so that the db can be in its own container if that makes sense
      • daMaestro
        pwnz0r, please also look at https://github.com/rpm-software-management/mock... for a proper build env
      • evansde77 joined the channel
      • pwnz0r, yeah and it's a docker anti-pattern to run more than one service in a single container
      • though it is possible and many are guilty of taking the easy way out ;-)
      • pwnz0r
        would that scenario work with subpackaging though?
      • daMaestro
        well sure. just don't Require the db server, just the libs in your -server subpackage
      • saschpe has quit
      • jeffreylevesque
        seems i don't have telnet
      • aveferrum: but, seems that the port was exposed - https://bpaste.net/show/0690029c6a46
      • pwnz0r
        ah i see i see
      • so i could break it down into something like myapp (all) and then myapp-server my-app-libs for example
      • saschpe joined the channel
      • aveferrum
        jeffreylevesque, yes it's now exposed. is the connection working?