Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    amchess
    @amchess
    for all containers at the same time
    Vincent Zurczak
    @vincent-zurczak
    Not sure. I am reading Marc's message about your plans. :)
    amchess
    @amchess
    ok
    everyway, thanks for your response
    overall for the tutorial not updated
    (your confirmation)
    Vincent Zurczak
    @vincent-zurczak
    OK. Marc indicated Docker as an intermediate solution to test Mongo and your Java web app. Right?
    amchess
    @amchess
    yes
    we wanted before a successful local test...
    on docker
    Vincent Zurczak
    @vincent-zurczak
    I would suggest switching directly to the third step, that is to say creating or updating a Roboconf application with your components. The graph part is fairly simple. What takes times is writing recipes. It all depends on how you deploy. There are 3 approaches to mix Roboconf and Docker, and the one you are using is not the best one (it is the oldest one and has many drawbacks). I suggest you use the "embedded" target handler to test locally.
    If your scripts manage Docker images, that will have no impact on your machine. You can use in-memory agents that will execute real recipes. And your recipes will be Docker containers. This way, you will be able to test locally and be able to switch seamlessly to a real IaaS.
    I'll check whether I have an example somewhere.
    amchess
    @amchess
    ok
    thanks
    And here, you have examples of Roboconf components / scripts that manage Docker containers. https://github.com/roboconf-recipes/docker-cassandra-cluster/tree/master/src/main/model/graph/cassandraNode/scripts
    This is how I manage Docker deployments now with Roboconf.
    With the "target.properties" file, agents are not running in Docker or on a VM. They run inside the DM.
    And they execute real recipes / scripts. And these scripts manage Docker containers.
    This way, you can test locally. Once you want to deploy on a real IaaS, just replace the "target.properties" file.
    Obviously, make sure to not rely on Docker links or networks. Inject the location of other components at startup.
    (location = IP)
    Vincent Zurczak
    @vincent-zurczak
    I do not know whether you have questions or not.
    I'll take a look at this chat tomorrow.
    As a summary, do not focus on using the "Docker target", use the "embedded" one instead.
    Vincent Zurczak
    @vincent-zurczak
    Hi. A night later, I have realized I told you something wrong. The example is right. But the target handler to use is not 'embedded", it's "in-memory". I had other things in mind yesterday, sorry.
    amchess
    @amchess
    what example do you mean?
    il est spécifié "in-memory"
    et je l'ai fait
    est celui de hier
    avec
    roboconf:target docker
    Vincent Zurczak
    @vincent-zurczak
    The example given above on Github... :/
    amchess
    @amchess
    ok, so it's confirmed the tutorial for docker is wrong and I have to focus on "embedded" target.
    Vincent Zurczak
    @vincent-zurczak
    "in-memory" ;)
    @vincent-zurczak
    Here: https://github.com/vincent-zurczak/cassandra-example-for-roboconf/blob/master/src/main/model/graph/VM/target.properties
    And here, you have examples of Roboconf components / scripts that manage Docker containers. https://github.com/roboconf-recipes/docker-cassandra-cluster/tree/master/src/main/model/graph/cassandraNode/scripts
    This is how I manage Docker deployments now with Roboconf.
    You mix what is in these two projects and that's it. You will have Docker deployments on your machine that can be translated to a real IaaS.
    And I think you should stop using the LAMP example, directly make your application, with Mongo and your Java application.