5 ms·

This right here. Can confirm, the #1 benefit of using Docker is that 98% of our "Ops" issues has gone away.

geggam 8y ago
No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent. Enjoy the learnings...
- andrewguenther 8y ago
  Three years in and this hasn't happened. Our dev team also does ops and we've found that Docker has improved things markedly. But feel free to keep spreading your FUD.
  - geggam 8y ago
    Curious... What is your setup ? AWS ? GCP ? ... managed k8s or you running it ? Outsourcing your operations and pretending the problem is cured by docker is just a bit silly.
    - andrewguenther 8y ago
      Docker on EC2. We had been running bare on EC2 before Docker using a homegrown chroot solution.
  - true_tuna 8y ago
    I’d love for this to be true. Have you had anyone come in and do an audit? I find crazy stuff when I show up at No Ops shops and poke around.
    - geggam 8y ago
      Last year we had a $NAME come for an audit. Well known company and they did not know how to audit inside containers. Still not sure how a corporation who runs RHEL contractually is able to use alpine and ubuntu based containers but it happens. I dont work there anymore and I am glad because when the containers finally do get an audit and the customer is told for X years they havent been in compliance.... well..
      - jcelerier 8y ago
        > Still not sure how a corporation who runs RHEL contractually is able to use alpine and ubuntu based containers but it happens. ... why would it be a problem ?
    - mbu 8y ago
      Can you expand on the crazy stuff you've seen?
    - andrewguenther 8y ago
      We've done two audits now, only minor items
- bunderbunder 8y ago
  There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved. (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.) If ops is involved, then there's no real reason they can't take charge of making sure that anything that is running in production is being built up from minimal images where they can keep track of the technology stack and all the different versions of xyz lib that are running in production. They've just got to do it using a different tool chain. And if ops isn't involved, I'm not sure how different this really is from the typical status quo, which involves unquestioningly running whatever uberjar full of unknown (to ops) 3rd-party packages that probably have their versions being selected using Maven's default version conflict resolution strategy, so that nobody, not even dev, really knows what exactly is running in production.
  - ravenstine 8y ago
    Your last argument is true of any software outside of the Docker ecosystem. Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? I don't believe anyone who answers yes, besides in the sense that NPM will produce vulnerability reports. If ops does their job well, that's great. A lot of people aren't that effective at their jobs, and if someone in ops is stuck in PHP Land, unwilling to learn Docker, they're going to become a huge bottleneck in short order. Some people are incompetent, but there is a lot of people who don't particularly like their jobs yet get a sadistic joy out of playing the gatekeeper role, being the ultimate decider of whether someone else gets what they want. All the worse if upper management sides with them by default since, well, they're the "webmasters". Yeah, I'm pretty biased because I've had situations like that on a few occasions. I'm not necessarily saying that the production situation is always improved by Docker, but what I described is not an uncommon situation and I think it often leads to teams gravitating towards Docker when their last person in ops finally leaves.
    - LoSboccacc 8y ago
      > Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? What, you don’t? Each dependency comes with a license notice. Everything needs to be pinned. The npm mess that comes out of pinning and unbounded versioning is precisely why we steer clear of it.
- ravenstine 8y ago
  I think the "issues" they are talking about are not necessarily the ones that ops people are meant to solve, but about the issue of ops acting as "gatekeepers" that often create perceived friction in the deployment(and even development) process. By Docker putting the power of what prerequisites are made available to individual applications running on servers, it bypasses the middle-man and gets the job done faster. That's not to say there aren't trade-offs when using Docker with ops as a service, but some (usually developers) would say the trade is worth it. Let's just hope they are writing their Dockerfiles with security in mind. :)
true_tuna 8y ago
Where do you run your containers?
- w8rbt 8y ago
  AWS Fargate. No infrastructure to patch or worry with. Just code and Dockerfiles.
  - workinthehead 8y ago
    You run your containers on a hypothetical platform that hasn't been released?
    - hadlock 8y ago
      We half of all our QA processes to Fargate sometime around April, more than halved our compute costs. After the big summer milestone there is another big project to move the rest to Fargate. I prefer running my own k8s/kops cluster, but our B team got it stood up in a week and have had no issues in at least a quarter.
    - w8rbt 8y ago
      You are misinformed. Fargate is out and it works. I have containers running on it right now and they have been for several weeks now. You can select it or the old EC2 approach. Try it, you may like it.

No they haven't. They are lurking around the corner waiting to hit you when you least expect it. The mugging you are about to get is what your ops team has had and are trying to prevent. Enjoy the learnings...

andrewguenther 8y ago
Three years in and this hasn't happened. Our dev team also does ops and we've found that Docker has improved things markedly. But feel free to keep spreading your FUD.
- geggam 8y ago
  Curious... What is your setup ? AWS ? GCP ? ... managed k8s or you running it ? Outsourcing your operations and pretending the problem is cured by docker is just a bit silly.
  - andrewguenther 8y ago
    Docker on EC2. We had been running bare on EC2 before Docker using a homegrown chroot solution.
- true_tuna 8y ago
  I’d love for this to be true. Have you had anyone come in and do an audit? I find crazy stuff when I show up at No Ops shops and poke around.
  - geggam 8y ago
    Last year we had a $NAME come for an audit. Well known company and they did not know how to audit inside containers. Still not sure how a corporation who runs RHEL contractually is able to use alpine and ubuntu based containers but it happens. I dont work there anymore and I am glad because when the containers finally do get an audit and the customer is told for X years they havent been in compliance.... well..
    - jcelerier 8y ago
      > Still not sure how a corporation who runs RHEL contractually is able to use alpine and ubuntu based containers but it happens. ... why would it be a problem ?
  - mbu 8y ago
    Can you expand on the crazy stuff you've seen?
  - andrewguenther 8y ago
    We've done two audits now, only minor items
bunderbunder 8y ago
There is only one possible place where this can really grow to be that kind of a problem: It's when ops isn't being involved. (And if the relationship between development and ops has broken down to the point that each one is trying to work around rather than with each other, you're already screwed. The rest is just details.) If ops is involved, then there's no real reason they can't take charge of making sure that anything that is running in production is being built up from minimal images where they can keep track of the technology stack and all the different versions of xyz lib that are running in production. They've just got to do it using a different tool chain. And if ops isn't involved, I'm not sure how different this really is from the typical status quo, which involves unquestioningly running whatever uberjar full of unknown (to ops) 3rd-party packages that probably have their versions being selected using Maven's default version conflict resolution strategy, so that nobody, not even dev, really knows what exactly is running in production.
- ravenstine 8y ago
  Your last argument is true of any software outside of the Docker ecosystem. Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? I don't believe anyone who answers yes, besides in the sense that NPM will produce vulnerability reports. If ops does their job well, that's great. A lot of people aren't that effective at their jobs, and if someone in ops is stuck in PHP Land, unwilling to learn Docker, they're going to become a huge bottleneck in short order. Some people are incompetent, but there is a lot of people who don't particularly like their jobs yet get a sadistic joy out of playing the gatekeeper role, being the ultimate decider of whether someone else gets what they want. All the worse if upper management sides with them by default since, well, they're the "webmasters". Yeah, I'm pretty biased because I've had situations like that on a few occasions. I'm not necessarily saying that the production situation is always improved by Docker, but what I described is not an uncommon situation and I think it often leads to teams gravitating towards Docker when their last person in ops finally leaves.
  - LoSboccacc 8y ago
    > Are you really going to read through every single directory in node_modules/ to make sure you know exactly what you're running? What, you don’t? Each dependency comes with a license notice. Everything needs to be pinned. The npm mess that comes out of pinning and unbounded versioning is precisely why we steer clear of it.
ravenstine 8y ago
I think the "issues" they are talking about are not necessarily the ones that ops people are meant to solve, but about the issue of ops acting as "gatekeepers" that often create perceived friction in the deployment(and even development) process. By Docker putting the power of what prerequisites are made available to individual applications running on servers, it bypasses the middle-man and gets the job done faster. That's not to say there aren't trade-offs when using Docker with ops as a service, but some (usually developers) would say the trade is worth it. Let's just hope they are writing their Dockerfiles with security in mind. :)

true_tuna 8y ago

Where do you run your containers?

w8rbt 8y ago
AWS Fargate. No infrastructure to patch or worry with. Just code and Dockerfiles.
- workinthehead 8y ago
  You run your containers on a hypothetical platform that hasn't been released?
  - hadlock 8y ago
    We half of all our QA processes to Fargate sometime around April, more than halved our compute costs. After the big summer milestone there is another big project to move the rest to Fargate. I prefer running my own k8s/kops cluster, but our B team got it stood up in a week and have had no issues in at least a quarter.
  - w8rbt 8y ago
    You are misinformed. Fargate is out and it works. I have containers running on it right now and they have been for several weeks now. You can select it or the old EC2 approach. Try it, you may like it.