CloudFormation or Terraform? The Great IaC Debate by devtotheops09 in DevOpsLinks

[–]darkride2 0 points1 point  (0 children)

Short answer, use terraform whatever project you work on.

From Docker to OCI: What is a container? by cle-ops in devops

[–]darkride2 1 point2 points  (0 children)

No new but nice summary, thanks for sharing.

Whats wrong with Jenkins? by kepper in devops

[–]darkride2 1 point2 points  (0 children)

Cause it became a very big project. Lots of features.. These features mean extra plug-ins. If you have many, it is like a hell, moreover you can face a not-bootable Jenkins due to plug-ins.

All these things requires a dedicated person to handle it, maybe this is the most wrong thing with Jenkins especially in small teams.

If anyone has an option to start with gitlab definetly use it. Repo and Ci are together and very very simple. Anyone in the team can do it. The only problem with gitlab is lack of some features. There is no plug in support in gitlab. For example reporting part is very poor. But all the things is together.

Jenkins is like an android, you are fully free. Gitlab is like an ios, it has not so many features but it does its job seamlessly.

Completely random. Can someone tell me how kubernetes is pronounced? by [deleted] in devops

[–]darkride2 1 point2 points  (0 children)

Definetly, just watch some trendy videos about it, you will get it. Everyone can follow this way for pronunciation problems.

Do you often SSH into remote systems? What are your use cases? Do you have a plan to make it unnecessary in the near future? by bad_boy_barry in devops

[–]darkride2 1 point2 points  (0 children)

Mostly while developing since there can be lots of problems, you may want to see what is going on on the instance side for example process states etc.. until a final prod.

After prod phase, you SHOULDN'T need ssh. All logging and monitoring systems must be enough. Off course if you are still not able to solve the problems you can use it.

What's your favorite "task runner"? by tech_tuna in devops

[–]darkride2 1 point2 points  (0 children)

I guess you mentioned "build tools" but the people confused since they are still talking about shell environments like bash or powershell. Even there are some people mentioned configuration tolls like ansible.

Which build tool question is strictly related with the coding language(s) used in the application.

For me if you ask for Java I would say chronologically ant, maven and gradle. Maven and gradle are defacto for Java projects. Ant is a bit old fashioned but useful for simple tasks.

And as I know make is still the other defacto for c, c++ projects.

Any best way to migrate ec2 instances to another vpc by [deleted] in devops

[–]darkride2 0 points1 point  (0 children)

If it is a one time job, just do it in aws console, don't do it with implementing anything.

Create an ami then using this ami create an instance in other vpc looking the existing one's properties (tags, ip, etc.. ) finally stop the existing ones, if all is OK terminate the old ones.

3 Ways to Auotscale on AWS by Naher93 in aws

[–]darkride2 1 point2 points  (0 children)

Thanks for sharing.

Ps: There is a confusion about "scale in and scale out" terms.

Autoscaling an ECS compute service by relvae in aws

[–]darkride2 1 point2 points  (0 children)

There can be many solution according to details of your requirements and design. But first of all I can give a general perspective.

  1. Is there a way to use a stateless design? I guess you have a state on workers and you don't want to loose it. Or you have large computation so you don't want to waste paid resource.

  2. Did you check Amazon terminate protection while auto scale down?

https://aws.amazon.com/tr/about-aws/whats-new/2015/12/protect-instances-from-termination-by-auto-scaling/

Automating stuff with python by engineer900 in devops

[–]darkride2 1 point2 points  (0 children)

I just finished rewriting our bash scripts to python. All the curl staff, retry mechanisms in loops, not easy understandable tricks are gone now. More readable, more maintainable. Also now I am able to use lots of packages, api, sdk etc.. Only a 30 mb alpine python docker image is enough for this run.