6 ms·

Care to expand on the portability and testing without containers?

by hoffs 8y ago

elbear 8y ago
You get portability by using any provisioning system: Ansible, Puppet, Chef. Although, it's not exactly the same thing, because with Docker you have everything already installed in the image. I've only used Ansible and I was never happy with its dynamic nature.
- viraptor 8y ago
  You don't get portability from chef and others. You get a framework where you can implement your deployment with a case for each system you want to target. Past some toy examples, it's on you to make it "portable".
  - elbear 8y ago
    By portability I was referring to being able to move your application to different servers by running your provisioning system.
  - larrywright 8y ago
    This is 100% correct. If you go look at the Chef cookbooks for any popular piece of software, say Apache or MySQL, the code is littered with conditional logic and attributes for different Linux distributions (not even considering entirely different operating systems). Every distro has different packages as dependencies, install locations, configuration file locations, service management, etc. Docker (all container solutions really) aren't a panacea, but they solve a very real problem.
- flossyspeaker 8y ago
  What do you mean by dynamic nature? Because how I've been using it it's very much static to what I have defined in my inventory.
  - elbear 8y ago
    I was referring to the language you write playbooks in (YAML). There are no static checks, other than a dry-run that only tests for syntax errors. Frankly, I haven't heard of any provisioning system written in a compiled language. I wonder why.
    - mdpye 8y ago
      NixOS kind of fits the bill (it can generate complete OS images from a recipe which is IIRC statically typed and "compiled") If it looks waaaay different to puppet, ansible and chef, there's a reason for that :) Doing provisioning "properly" means managing every file on the drive...
      - elbear 8y ago
        I know about nix, but I'm referring to the language you use to describe the final image. Actually, this part is not a problem. The problem comes in the deployment part. For example, there's no concept of `Maybe this request failed, you should handle it`. So when you run the deployment script, the request fails and the rest of your deployment process. Defining the possibility of failure with a type system would force you to handle it in your deployment code and provide a backup solution.

Care to expand on the portability and testing without containers?

by hoffs 8y ago

Care to expand on the portability and testing without containers?

You get portability by using any provisioning system: Ansible, Puppet, Chef. Although, it's not exactly the same thing, because with Docker you have everything already installed in the image. I've only used Ansible and I was never happy with its dynamic nature.

viraptor 8y ago
You don't get portability from chef and others. You get a framework where you can implement your deployment with a case for each system you want to target. Past some toy examples, it's on you to make it "portable".
- elbear 8y ago
  By portability I was referring to being able to move your application to different servers by running your provisioning system.
- larrywright 8y ago
  This is 100% correct. If you go look at the Chef cookbooks for any popular piece of software, say Apache or MySQL, the code is littered with conditional logic and attributes for different Linux distributions (not even considering entirely different operating systems). Every distro has different packages as dependencies, install locations, configuration file locations, service management, etc. Docker (all container solutions really) aren't a panacea, but they solve a very real problem.
flossyspeaker 8y ago
What do you mean by dynamic nature? Because how I've been using it it's very much static to what I have defined in my inventory.
- elbear 8y ago
  I was referring to the language you write playbooks in (YAML). There are no static checks, other than a dry-run that only tests for syntax errors. Frankly, I haven't heard of any provisioning system written in a compiled language. I wonder why.
  - mdpye 8y ago
    NixOS kind of fits the bill (it can generate complete OS images from a recipe which is IIRC statically typed and "compiled") If it looks waaaay different to puppet, ansible and chef, there's a reason for that :) Doing provisioning "properly" means managing every file on the drive...
    - elbear 8y ago
      I know about nix, but I'm referring to the language you use to describe the final image. Actually, this part is not a problem. The problem comes in the deployment part. For example, there's no concept of `Maybe this request failed, you should handle it`. So when you run the deployment script, the request fails and the rest of your deployment process. Defining the possibility of failure with a type system would force you to handle it in your deployment code and provide a backup solution.