DevOps Asked on November 12, 2021
Once again company debate rages on who should write Docker files (including compose, interchangeable for this post).
The scenario is common in my work (developer and consultant) and I wanted to know if there is a hard and fast rule for the creation and management of Docker files. I have operated in the following three scenario:
1.) Dev-ops writes and manages the Docker files
Pros: they don’t have surprises for production and ultimately control the final instance
Cons: Devs are less informed on Docker/server, have to wait for certain changes or ask permission or need an ops team person to do something like add an environment variable
2.) Developers write and maintain Docker files
Pros: Devs keep on working, collisions and conflicts are resolved inside that team
Cons: Dev-ops often is handed a bad or troubling Docker file for production. Dev ops also spends time fixing developer problems on the Docker file. Developers generally do not focus on security with respect to instance.
3.) Hybrid approach: Devs write the Docker file for their use in conjunction with dev-ops policy or needs. Dev-ops bases a different production docker file on the developers working Docker file but add in secret handling, Terraform/IaC/CI+CD needs, and takes responsibility for Docker files running on instance.
In this scenario dev-ops teams watched our (developer) files and used the differentials to ask questions or provide insight into changes.
—
The problem I run into over and over (regarding Docker files):
The list of experienced problems is quite long, but I hope this is enough information to establish a dialog on this topic from the professionals who handle Docker the most and take responsibility for uptime.
23July Responding to @MLu:
Dev ops is "Developer Operations", as in the deploy and infra side of things. "Working together" always happens, but these are two distinct career paths and domain of expertise (developer and operations). As the Wikipedia entry underscores my view, there is note regarding context dependence on the paradigm. Dev writes the code, Ops puts to instance, in the middle there is collaboration. So I don’t agree at all that "DevOps model is exactly the blend of these two roles.", not in my 17 years on many teams.
One of the teams was considered "SRE" while another liked "Devops", and another "Infra (not even answering people who use devops)". Each team had their own ideas but the same problems in the end servicing the development aspect of projects.
Development and "Ops" as in CI/CD need to work together, but for some reason only these "ops" teams in all scenario were the acknowledged pain point. Why is this so common?
If DevOps is born of developer practices (agile, reliance on SCM, DRY, etc) and usually staffed by a high percentage of ex-developers why is the staffing diaspora in build/ship/pipeline generally slow to react or respond, require long lead time, and are generally the most common blocker on projects. I question the ivory castle declarations from these ops teams. When a team is overloaded, under performing, and diverges from established norms then the (the dogma of) "X needs to do the Y" could be a solution or grasping at straws?
I do agree with @MLu’s commentary on management of Docker files via PR and other approaches outlined. I read the response as a hybrid approach that I prefer.
Frustration is rooted in a few projects where I was "Devops" and we had cloud based products with complicated CI/CD and other operations. Yet we never had devops problems. As soon as a dedicated team handles these elements things would slow down, uptime suffered, and the product release cycle was more stressful. A cadre of us are discussing alternatives to the current paradigms because we are repeating the same problem over and over, both in an org and across different jobs.
I find this to be an organisational question.
There are many approaches to this, but I find there are 3 distinctive types:
If the product teams themselves can do the DevOps, the DevOps part could have one or more responsible persons who are well educated on the matter and that would review pull requests from the DevOps perspective.
A DevOps team could even store their code in separate repositories that only they have access to and could work together on solving the issues.
A DevOps engineer could also work with many teams offering assistance when needed, if the burden isn't much. Say you have 8 products and 2 DevOps engineers that each are responsible for supporting 4 products.
One crucial difference is how knowledge is shared but also responsiveness. Dedicated DevOps engineer can focus on solving the problems for the product team while shared engineers and teams ultimately would have to prioritise between the products which will create delays - what DevOps is supposed to prevent. Hence, all teams should have people with basic DevOps knowledge, but there should also be people with extensive knowledge and experience available.
Personally I don't find the "DevOps team" approach good, I find that it's pretty much just a rename of the operations team - but it's a good start! A better approach could be having a DevOps lead and regular meetings where knowledge could be shared.
Answered by Mikael Dúi Bolinder on November 12, 2021
I agree with MLu although my experience is generally in small teams where roles tend to get a bit blurred anyway. Taking the 'infrastructure as code' approach that led to dev ops, the dev ops team should be collaborating with the dev team just like the dev team collaborate internally to ensure features work together. Perhaps having separated teams is the problem and instead you should have project based teams that include all specialities working together. Again my experience is in small startup environments so this may be a big shift in a larger organisation used to departmentalisation.
Answered by sam on November 12, 2021
Isn't DevOps .. you know .. Devs and Ops working together, ideally in the same team?
What you refer to as Dev-ops in your post sounds very much like the traditional Operations - developers build something and hand it over to Operations for deployment. Well that's not DevOps.
DevOps model is exactly the blend of these two roles. Not necessarily in one person but ideally in one team. Some people in the team write the actual code and tests, some maintain CI/CD pipelines, some write packaging / build / Docker files, some look after deployment. All the above ideally driven by CI/CD so that most people in the team can focus on writing code. Building, packaging, testing, and deployment happens automatically.
In our team the Dockerfiles are in the same repo as the software sources we work on and any developer can update it if needed (through a PR of course). The deployment files (AWS CloudFormation, Terraform, etc) are in another repo and again anyone can update these through a PR. Once any change (source, Dockerfile, CloudFormation, ...) is committed and pushed to git it automatically builds and deploys to Dev environment.
Single click in the CI/CD interface can then promote it to Test and another click to Qual and then to Prod.
TL;DR What you describe is not DevOps but instead a traditional Dev and traditional Ops fighting each other ;)
Answered by MLu on November 12, 2021
Get help from others!
Recent Answers
Recent Questions
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP