5 ms·

My experiments with lxc-attach always failed; presumably my kernel was wrong in some way (I followed instructions to get to 3.8, but I am sufficiently clueless

by seldo 13y ago

My experiments with lxc-attach always failed; presumably my kernel was wrong in some way (I followed instructions to get to 3.8, but I am sufficiently clueless that I wasn't sure it had worked, or that it was the right flavor of 3.8). But that's only the ad-hoc case: the bigger question is, if you have an image with instructions "RUN apt-get install mysql", you're not even halfway to having a copy of MySQL you can run in production: at a minimum you'll need to install a custom my.cnf to suit your application's operational parameters[1], but really you'll want it to be slightly different every time -- new bind addresses, potentially new master-slave relationship grants, etc.. The way docker images interact with configuration management in a grown-up production environment is still really hazy to me. [1] We are all agreed that running default my.cnf in production is laughable, yes? That information has filtered into the mainstream from the DBA crowd?

nickstinemates 13y ago
How I would personally tackle that specific problem is the following: 1) Create a Dockerfile which installs the dependencies of my image as a base (maybe in this case all it is is RUN apt-get install mysql) 2) Tag the image as mysql-base. 3) Shell in to mysql-base, and iterate over the changes as needed until its 'production ready.' 4) Once it's suitably 'production ready', `docker diff` the version to see which files changed. 5) Here comes the fork in the road. Either go back and instrument my original Dockerfile to modify the files that were updated to make my image production ready, OR, `docker commit` that image. There are benefits to both sides, but ultimately it will be up to you in terms of maintainability. The definition of 'production ready' will differ from org to org. 6) Push the final image to a private registry.
- contingencies 13y ago
  With step #1 ... apt-get install mysql ... what happens when the network repos go down? Like when you have to rebuild the same system four years later? You might wind up with an epic fail. That's not very stable as a packaging format then, is it? But this is just an example challenge from a much larger set... all of which derive from the fact that state is being allowed to seep in from random places. It's not clean. This is essentially one of the core complaints I have with some of these tools. In my own as-yet-unfinished tool's architecture that tackles similar domains, network access is disallowed at deployment time. If a package cannot be installed without network access, then it is not considered a valid package.
  - nickstinemates 13y ago
    It all depends on your tolerance threshold and the trade-off's that are involved to make an acceptable decision. If you expect apt-get install mysql to fail in the future, there are plenty of mitigating factors (storing the build/deps on your local repo, building from source..) My point is, you can always find pathological cases. Discussing them is great as a straw man for improvement, but not really useful beyond it.
    - contingencies 13y ago
      Right, my tooling generally builds everything from source (mostly gentoo is the target platform, though also ubuntu) and generates the deps automagically. This is achieved by viewing 'build' and 'install' for the cloud-capable service package as two separate steps, ie. build is the 'gather all requisite goodies' step, and then a version is applied. 'Install' is where an instance is actually created on top of a target OS platform image (also versioned). Apparently what I consider fundamental architectural issues you see as pathological cases. Your call! :) Take for instance multiple cloud providers. Those guys are notorious for giving you a slightly different version of any OS as a stock image, and running slightly different configurations. Some of them even insert their own distro-specific repos/mirrors. In that case, you are going to see entire classes of weird and subtle bugs appear where you either: (A) are not using the same cloud provider for test/staging/production environment. (People tend to lean on local virt for the former). (B) try to migrate (eg. due to cloud provider failure, hacks, bandwidth or scaling issues, regulatory ingress, etc.) to another provider That's not unrealistic, IMHO.
      - nickstinemates 13y ago
        > This is achieved by viewing 'build' and 'install' for the cloud-capable service package as two separate steps, ie. build is the 'gather all requisite goodies' step, and then a version is applied. 'Install' is where an instance is actually created on top of a target OS platform image (also versioned). This doesn't apply to Docker. You can use the exact same process. > Take for instance multiple cloud providers. Those guys are notorious for giving you a slightly different version of any OS as a stock image, and running slightly different configurations. Some of them even insert their own distro-specific repos/mirrors. In that case, you are going to see entire classes of weird and subtle bugs appear where you either These are not issues with Docker. The Dockerfile specifically states its environment, so it matters not what the cloud providers use on their host image.
jpetazzo 13y ago
If you are on Linux 3.8, lxc-attach should work. I use it on a regular basis and never saw any problem (as long as I was on Linux 3.8). The exact syntax is "lxc-attach -n $FULL_CONTAINER_ID", and you can get the full container ID with "docker inspect" (or "docker ps -notrunc"). Agreed on the my.cnf points, indeed :-)

by seldo 13y ago

nickstinemates 13y ago

How I would personally tackle that specific problem is the following: 1) Create a Dockerfile which installs the dependencies of my image as a base (maybe in this case all it is is RUN apt-get install mysql) 2) Tag the image as mysql-base. 3) Shell in to mysql-base, and iterate over the changes as needed until its 'production ready.' 4) Once it's suitably 'production ready', `docker diff` the version to see which files changed. 5) Here comes the fork in the road. Either go back and instrument my original Dockerfile to modify the files that were updated to make my image production ready, OR, `docker commit` that image. There are benefits to both sides, but ultimately it will be up to you in terms of maintainability. The definition of 'production ready' will differ from org to org. 6) Push the final image to a private registry.

contingencies 13y ago
With step #1 ... apt-get install mysql ... what happens when the network repos go down? Like when you have to rebuild the same system four years later? You might wind up with an epic fail. That's not very stable as a packaging format then, is it? But this is just an example challenge from a much larger set... all of which derive from the fact that state is being allowed to seep in from random places. It's not clean. This is essentially one of the core complaints I have with some of these tools. In my own as-yet-unfinished tool's architecture that tackles similar domains, network access is disallowed at deployment time. If a package cannot be installed without network access, then it is not considered a valid package.
- nickstinemates 13y ago
  It all depends on your tolerance threshold and the trade-off's that are involved to make an acceptable decision. If you expect apt-get install mysql to fail in the future, there are plenty of mitigating factors (storing the build/deps on your local repo, building from source..) My point is, you can always find pathological cases. Discussing them is great as a straw man for improvement, but not really useful beyond it.
  - contingencies 13y ago
    Right, my tooling generally builds everything from source (mostly gentoo is the target platform, though also ubuntu) and generates the deps automagically. This is achieved by viewing 'build' and 'install' for the cloud-capable service package as two separate steps, ie. build is the 'gather all requisite goodies' step, and then a version is applied. 'Install' is where an instance is actually created on top of a target OS platform image (also versioned). Apparently what I consider fundamental architectural issues you see as pathological cases. Your call! :) Take for instance multiple cloud providers. Those guys are notorious for giving you a slightly different version of any OS as a stock image, and running slightly different configurations. Some of them even insert their own distro-specific repos/mirrors. In that case, you are going to see entire classes of weird and subtle bugs appear where you either: (A) are not using the same cloud provider for test/staging/production environment. (People tend to lean on local virt for the former). (B) try to migrate (eg. due to cloud provider failure, hacks, bandwidth or scaling issues, regulatory ingress, etc.) to another provider That's not unrealistic, IMHO.
    - nickstinemates 13y ago
      > This is achieved by viewing 'build' and 'install' for the cloud-capable service package as two separate steps, ie. build is the 'gather all requisite goodies' step, and then a version is applied. 'Install' is where an instance is actually created on top of a target OS platform image (also versioned). This doesn't apply to Docker. You can use the exact same process. > Take for instance multiple cloud providers. Those guys are notorious for giving you a slightly different version of any OS as a stock image, and running slightly different configurations. Some of them even insert their own distro-specific repos/mirrors. In that case, you are going to see entire classes of weird and subtle bugs appear where you either These are not issues with Docker. The Dockerfile specifically states its environment, so it matters not what the cloud providers use on their host image.

jpetazzo 13y ago

If you are on Linux 3.8, lxc-attach should work. I use it on a regular basis and never saw any problem (as long as I was on Linux 3.8). The exact syntax is "lxc-attach -n $FULL_CONTAINER_ID", and you can get the full container ID with "docker inspect" (or "docker ps -notrunc"). Agreed on the my.cnf points, indeed :-)