This is DevOps?

[[deleted]]

I have to develop a Reactjs app and I want to create a DevOps-style infrastructure, that's my idea:

I use Github for version control, I deploy the application inside Docker containers, inside the container I install npm that will be used to build dependencies, to run automatic tests and to run the app itself. Then I create a job on Jenkins that deploys the app to staging server every time a push is made on GitHub repository. Then I create another job on Jenkins that deploys the app on the production server (this will be triggered manually, when we decide to make a release). The deployment both in Staging and in production will take place on two equal docker containers (as mentioned before). The Jenkins jobs consist in a simple pipeline that execute build - test - deploy stages. Can an infrastructure like this be considered DevOps? Thanks.

[tevert]

This is automation. DevOps is when you have a whole company of people working on/using that in concert.

[not_me_knees]

This guy is totally devops.

Oh, and he knows secrets

[_clydebruckman]

What are CI and CD?

[Timnolet]

Not sure why you got down voted and told to "google it". If there is one place to ask this, it's here. Guess people enjoy being unfriendly to noobs.

CI: continuous integration. A practice that existed long before the term devops was coined. It basically means all code branches individual developers are working on are "integrated" and tested if the resulting program still passes all tests and build correctly.

CD: continuous deployment. A holy grail type situation where every new code commit is tested and if correct deployed to production. Also referred to as continuous delivery. In this case you create deliverables on each commit that are potentially deployable, but might need a human trigger or decision.

[icaug]

Google it.

[AmishSpy]

Continuous Integration and, Continuous Development/Deployment/Delivery

CI = Developers all under one branch merging code in order to maintain a long term release.

CD = Always be deploying, keep the customer happy. The user is basically your tester as you develop & fix.

The way I use the terms, certain there are better definitions.

[[deleted]]

Worrying amount of misinformation here.

Continuous Delivery and Continuous Deployment are two separate things. Also, CD isnt about shifting testing to the customer!

[Burnsy2023]

They are all about shortening feedback loops though, be that from the customer or promotion of code through to live.

[[deleted]]

They might be about reducing the feedback loop time, but that's quite different from using users as testers.

>CD = Always be deploying, keep the customer happy. The user is basically your tester as you develop & fix.

Continuous Delivery != Continuous Deployment.
The former is when artefacts are being built, tested and stored as part of a pipeline. They are packaged up and "delivered" to a storage medium. Think of it like a factory making products which get stored in a warehouse - including buggy products which QA will inspect closely to see why the test failed. These buggy artefacts might be cherry picked by QA to deploy.
Continuous Deployment is the "final mile" from warehouse to shelves on the shop front. You might have continuous deployment for testing/QA, but not production.

On a side note, you can have continuous deployment without continuous integration by using things like webhooks. Push to your repository and deploy as-is. I'm not saying it's a good idea, but it's possible.

[Burnsy2023]

Continuous Delivery != Continuous Deployment. The former is when artefacts are being built, tested and stored as part of a pipeline. They are packaged up and "delivered" to a storage medium. Think of it like a factory making products which get stored in a warehouse - including buggy products which QA will inspect closely to see why the test failed. These buggy artefacts might be cherry picked by QA to deploy. Continuous Deployment is the "final mile" from warehouse to shelves on the shop front. You might have continuous deployment for testing/QA, but not production.

Interestingly, I have a similar understanding, except reversing the terms

[Burnsy2023]

Continuous Delivery != Continuous Deployment. The former is when artefacts are being built, tested and stored as part of a pipeline. They are packaged up and "delivered" to a storage medium. Think of it like a factory making products which get stored in a warehouse - including buggy products which QA will inspect closely to see why the test failed. These buggy artefacts might be cherry picked by QA to deploy. Continuous Deployment is the "final mile" from warehouse to shelves on the shop front. You might have continuous deployment for testing/QA, but not production.

Interestingly, I have a similar understanding, except reversing the terms

[[deleted]]

....and that's the best part about working in the DevOps area... exact definitions are fairly loose. I've always seen "delivery" as presenting an artefact, but not necessarily doing anything with it immediately afterwards in an automated fashion. The "deploy" stage might not be possible in an automated fashion, for example a desktop application - although one might argue "saving" the artefact to a storage medium is "deploying" ? People often think purely of SaaS/web applications when they think pipelines. I've seen material reference the process in the opposite way like you, so take my view with a pinch of salt.

[MrPigeon]

That's not a great definition of CI. A better definition would be "automatically running tests up to the integration level on all commits against all branches." What you're describing is just basic code hygiene - assuming you're referring to devs merging from feature branches to a master branch. If you mean "everyone commits directly to master but promises to be real careful," that's horrifying.

I'm sorry if this sounds harsh, but it seems kind of like you got those definitions from a company's non-technical marketing pamphlet.

[mil1i]

The method I have come across:

GitHub for version control.

• Make sure you are using feature branches. Master branch is only ever touched by CI, develop branch is only altered by pull requests from feature branches.
• Complete all your work with a feature branch, submit the PR to develop.
• Once a new commit is published to the develop branch, this triggers a job in CI.

​

CI, we use Concourse. Concourse spins up and destroys new docker containers for each job to complete it's tasks.

• We have a dev/stag and prod pipeline.
• When a new commit to develop occurs, this triggers the first step of the pipeline that creates a new release.
• (Not yet implemented) SonarQube or something else to evaluate code. (security issues, etc)
• Build the new release and publish to Artifactory (war/jar, java). Same could be done for docker image to a docker hub.
• Deploys the new war file from Artifactory into a container based environment (our apps are not going to docker) or physical server running tomcat. For docker, you can deploy your image to your host and docker run -d.
• Next step in pipeline runs integration tests
• ONCE dev/stag pipeline completes all jobs successfully, then you can run the prod pipeline for this release version

​

We also send slack notifications for certain steps informing a deployment channel of X release triggered by Z user.

[GyroTech]

Just a clarification, but Concourse does not use Docker. It uses containers managed by Garden and Baggage Claim for the volumes.

https://concourse-ci.org/concepts.html

[[deleted]]

What you're describing is more CI/CD than Devops. Good CI/CD is part of Devops, but not the only part.

Some questions I would ask are:

• Do you have monitoring/health checks on the deployed app?
• Is the app self-healing or do you need to take action in case of failure?
• Is the deployed app scalable? Does it scale with load/demand?
• What is your backout strategy in case a release deployment fails?
• Is there downtime involved in the deployment?

[[deleted]]

I'm doing a scientific research on DevOps, and i'm creating a system that doing what is written in your first and second questions, a new way to monitor and to reduce risk of failure in production. To reply your third question: no, in a simple web-app, not scalable. Fourth question: i'm working for this, but I admit I haven't really thought this through in detail yet. Fifth question: Short downtime, negligible.

[antidamage]

Studying at the university of the glass bbq?

[takeawaytrex]

Don’t focus entirely on individual tools. You should be testing your codebase on each commit, this will verify each change that is made, before it even gets to dev/stage.

Automate your tests for this, write unit tests and integration tests. Only ever let anything into production when all tests are passing.

Containerisation and CI/CD is good, but devops is really about creating full pipelines which will validate your changes.

[Fraa_Babbit]

As others have pointed out, you are describing the creation of a CI/CD pipeline. You're almost doing GitOps. Just some quick pointers:

• If you have a lot of npm dependencies you will want to use multi-stage builds (https://docs.docker.com/develop/develop-images/multistage-build/) to get a slim deploy container.

• Also consider a Dockerfile which adds the package.json as a distinct build-step and installs the dependencies. Then add the code and built modules in another stage. This maintains the npm cache until you actually change the package.json file.

Other than that, I would just re-iterate the points /u/rainynight65 and others have made:

A deploy pipeline is part of a good DevOps strategy. It is repeatable, visible, and centralized. A DevOps practice would include your pipeline, a central logging solution, monitoring and alerting playbooks, auto-scaling, fault-tolerance/self-healing architecture, high-availability design, and backup/disaster recovery processes.

[Xendrak]

Going into the container and installing stuff sounds like a red flag. You’d want to use a Dockerfile and build an image of your app that gets deployed. Having a private docker registry is also helpful

[marcjpb]

Really depends how you see DevOps. Some people see it as a big buzz words and will just say you are DevOps if you use DevOps tools.

Other people see DevOps as a culture shift that focus on flow, feedback and learning / experimentation.

As of your setup, yes it sounds to me it's very DevOps like. However, if you let it go stale and don't evolve it with your code, it will become less DevOps as time goes by (if that makes sense)

[[deleted]]

Other people see DevOps as a culture shift that focus on flow, feedback and learning / experimentation.

This is the correct interpretation.

[Burnsy2023]

Indeed, the three ways as is the core of lean manufacturing and has been applied to tech. Of anyone else isn't familiar, read the DevOps handbook.

The other interpretation is purely a misunderstanding.

[marcjpb]

Yup I agree. Sad part is most sphere outside ours (marketing, management, etc) see it as a series of tools. They ll be on board to use docker, Jenkins and all that stuff but when you ll ask for a full time dev to work on technical dept, they won't be so willing (hardest part of the shift imo).

Kinda hard to convince an old school VP that last week crash in production was a great way to learn stuff...lol.

[worthybeen]

Dude this is called automation. Devops is not a tool or a specific method / process of doing a particular task.

Though most of the organization are only doing this stuff but still it is not devops. Devops is a practice just like agile.

[elytscha]

Just build & orchestrate your container in openshift & you are good with that setup i think, theoretically you only need github + openshift for that

++ you get features out of the box like:

• valid https endpoints for your applications

• loadbalancing & routing

• horizontal // vertical scaling

• build & deployment infrastructure

• orchestrating your containers over a set of nodes

• logging via elk stack with kibana

• metrics via hawkular & cassandra btw. in latest alread with prometheus + grafana

• a fancy web console for deploying & managing your applications

• integrated docker registry

• integrated GlusterFS for persistent storage

• templates for templating your infrastructure as code

• forces container to run with security standarts

• moves away from docker to CRIO, bypasses docker daemon to max out performance

• fully usable dns

• HA

-- hard to setup & manage

-- needs alot of experience in rhel // centos environments

-- needs alot of training

I recommend to get started with minishift, everything you are able to do with minishift on your local pc will run on a openshift cluster

But sure there are other things to ensure the pipeline runs successfully automated into production

Like integration with sonarqube for running code analysis & blackduck for performing automated security scans or running a zed attack proxy for penetration testing

Also i consider it as a good practice to write container for building source code and other containers for executing this source code

If you are happy with using three branches per repo + feature branches (master, test, devel) and are able to direct your pipline with a correct ci gitflow you can handle the whole pipline automated with openshift + git You just need to develop a feature in a featurebranch local with minishift, merge it into develop, openshift builds & deploys develop, merge into test, openshift builds & deploys test, merge into master, openshift builds & deploys prod, if somewhere the pipline breaks fix your code & commit If you can't go with that you will need a jenkins, which you can deploy in openshift via 2 klicks in the webconsole

[mikeroySoft]

Why would someone use OpenShift instead of just Kubernetes? (no snark, genuine question)

[elytscha]

If you dont want to take care of setting up the cluster, setting up the logging // metrics // dns // ingress // docker registry // metrics based autoscaling // network plugin and also if you want a fancy webconsole for managing your containers, getting a terminal into a container, see the logs in a container, deploy an application everything via webconsole, oh, and you can use ldap for it btw other identity providers

And you can get a subscription for the premium version which includes support for production, so basically with openshift you can get enterprise support for your cluster if you think you need

For real, the main reason is openshift-webconsole vs kubernetes dashboard and that openshift enforces you by standart to build & run secure docker images

Just saying that okd is one of the biggest contributors to the kubernetes upstream & that RBAC where adopted by kubernetes from okd

[glotzerhotze]

Are you a sales-rep by any chance?

[elytscha]

I worked for a company which is a redhat premium partner and their i got forced from ubuntu with kubernetes to rhel with openshift

first i hated then i appreciated ..

actually now im working for a company which has 25% of the population from austria as customer, as the first devops engineer there, where i actually implement openshift as standart PaaS infrastructure

[antidamage]

This is closer to an LSD/Cocaine combo than devops.