Looking for a system for sending out system status and planned maintenance by email

Hi,

I'm looking for a system to easily send out notifications to our customers when a service degrades/downtime on a service, and optional for planned maintenance.

We have a system where we have several middleware servers, and several customers with frontend-services on top of this middlewareservers.

I looking for a service for quickly sending out notifications to the affected customers. I.e customerA should be notified when we detect errors on customerA-frontend, and a predefined set of middleware-servers that affects customerA.

I have looked at [sorrypage.app](https://sorrypage.app) et al, and I like it's structure with components etc, but I don't want a public statuspage, but only notification by mail.

The closest I have found is using mailchimp and tags, i.e tag a customer contact info with "customerA", and for example "middlewareC" and "middlewareE" - but it really like a tools special made for this, with nice, (predefined) templates.

​

Any tips?

https://redd.it/epges2
@r_devops

ISPconfig for docker ?

I have multiple web servers running remotely, I’d like something to manage them just like ISPconfig (chroot dir, setup ftp users, manage configs) is there anything on the market for this ?

My only alternative right now is to stop using dockerized setups in favor of the old fashioned setup nginx and php-fpm on each server so I can use ISPconfig but I really like being able to tinker with upgrading my containers to the latest php etc without hassle

What are you guys doing or using to make life easier ?

https://redd.it/epg2m1
@r_devops

In looking for work, the most common and difficult interview question is how I would diagnose performance issues between multiple tiers and/or services, cloud or bare metal. What's your answer to this?

The problem is in the subject.

I have a fair understanding of this and don't wash out, but I feel like my response is sub-par and not on point.

How do I respond to this question as a generalist being interviewed?

https://redd.it/epfl2i
@r_devops

Is sentry.io only monitoring errors or can I use is as a cross-project centralized logs platform?

I know that it supports many cool frameworks which could help me a lot during development of some apps, but I am wondering whenever it can gather rather simple, not error related logs from the projects?

If there is anything else you can suggest as an alternative then please, share.

I intend to self-host a [sentry.io](https://sentry.io) since they provide clean docker-compose file

Especially I am looking into a possibility of live-tracking logs messages from frontend app and backend API (at one screen) which could possibly help me with debugging async apps.

https://redd.it/epdtxp
@r_devops

Secure Kubernetes on Hetzner Cloud with a node driver for Rancher

Hi! I wrote a post on how to deploy Kubernetes to Hetzner Cloud (a cheap and very good cloud provider from Germany) using a node driver for Rancher. The node driver is very convenient, but requires that a firewall is configured separately, which is what I show in this post. Any feedback is much appreciated!

https://vitobotta.com/2020/01/17/secure-kubernetes-hetzner-cloud-rancher-node-driver/

https://redd.it/eq1bbw
@r_devops

Hi r/devops, we recently open sourced a command-line cloud automation tool and would love to get feedback on it. We've been using a version of this tool internally for many years and decided to clean it up and open source it.

Disclaimer: I'm co-CTO at Perfect Sense, the company that built Gyro, and the original author of the tool.

With that out of the way, we'd love to get feedback (good or bad) on Gyro. If you've ever used Terraform or Cloudformation you'll feel right at home with Gyro. It allows you to automate any cloud provider with an API. Currently we have good (but not yet 100% of resources) support for AWS and Azure. We're working to add Google Cloud support.

Gyro evolved from an internal tool we built starting way back in 2014. The initial goal of that tool was to automate creating and updating our infrastructure. As time went on we integrated various parts of our infrastructure into this tool. For example, we used it to execute Chef Solo on our hosts, ssh into hosts, interact with our service discovery, and deploy our code using with blue/green deployment model. We found this "one tool for most of your day-to-day ops activities" to be extremely valuable. This is why we decided to refactor the code, make it more flexible, and open source it so others could do the same.

Why the name Gyro? It's short for Gyroscope which is an essential device that allows airplanes to navigate in the clouds. I love aviation. Also, if you read "gyro" and thought of a greek sandwich, you're not the first, definitely won't be the last, haha. That's ok though, gyro sandwiches are super yummy. :)

There are a few things that make Gyro different from similar tools. I'll try to highlight those here but encourage you to read either the developer documentation site ([https://gyro.dev](https://gyro.dev/)) or if you want a higher level quick hits page read [https://getgyro.io/introducing-gyro](https://getgyro.io/introducing-gyro).

**1) Simple: Configuration Syntax (aka the Gyro Configuration Language)**

I know, I know, another Yet Another DSL. Originally we wrote this using YAML but we wanted clean (and limited) logic in our configuration and YAML didn't really fit the bill. We tried a few different language based internal DSLs such as Kotlin, Groovy, and even TCL (don't hate) but the language always bled through and didn't feel right.

Ultimately we decided to design our own simplified, but powerful, language. This allowed us to have greater control over scoping rules, control structures, and runtime execution. Building a tool that generates an internal graph of resources is extremely complex and not having complete control over what is happening during execution makes it much more complex.

[https://gyro.dev/guides/language/](https://gyro.dev/guides/language/)

**2) Logic: Control Structures**

We're well aware of the ongoing debate of whether allowing logic (control structures) in a configuration is a good thing or not. We believe it is as long as you provide reasonable limits. We tried to strike a balance between no logic and a full programming language. To start with we've implemented two control structures we think are most important for configuration logic, "if" and "for".

Control structures are actually an extension of Gyro rather than baked into the language parser.

[https://gyro.dev/guides/language/control-structures.html](https://gyro.dev/guides/language/control-structures.html)

**3) Workflows**

We think this is huge. What we mean when we say workflows is the ability to define transition stages for complex cloud infrastructure updates. Blue/green deployments are a good example of this. With Gyro you can define a stage to create a new load balancer and new virtual machines with your updated code. After this stage executes you can either prompt the user to continue allowing them to validate the new deployment or you can automate it with simple logic. The next stage you define can either drop those new machines into the load balancer taking traffic or you can flip DNS depending on how you like to do blue/green. If at any poi

nt things don't look right Gyro can roll back to a previous stage.

This functionality has been extremely important for us to be able to allow people to do deployments and to quickly roll back should anything go wrong.

[https://gyro.dev/guides/workflows/](https://gyro.dev/guides/workflows/)

**4) Extensibility**

Aside from workflows, extensibility is what I'm most excited about in Gyro. We've included a number of ways you can extend Gyro with plugins.

* Add new commands ([https://gyro.dev/extending/commands/](https://gyro.dev/extending/commands/), [https://github.com/perfectsense/gyro-ssh-plugin](https://github.com/perfectsense/gyro-ssh-plugin))
* Add new language functionality, aka Directives ([https://gyro.dev/extending/directive/](https://gyro.dev/extending/directive/))
* Add custom variable resolvers ([https://gyro.dev/extending/resolver/](https://gyro.dev/extending/resolver/))
* Add custom event hooks (undocumented) to trigger custom logic when various things happen such as a resource is created or updated

TL;DR Check out [https://gyro.dev](https://gyro.dev/) or [https://github.com/perfectsense/gyro](https://github.com/perfectsense/gyro), this the developer/user documentation for Gyro and the main repo. It should give you a good idea of what Gyro is and how it works!

https://redd.it/eq023h
@r_devops

Run pre-deployment policy checks on Terraform using Open Policy Agent with Regula

Hi everyone. We just open sourced Regula, a tool that evaluates Terraform infrastructure-as-code for policy prior to deployment. Regula includes a library of rules written in Rego, the policy language used by the Open Policy Agent project. Where relevant, we’ve mapped Regula policies to the CIS AWS Foundations Benchmark, and we'll be adding more rules as we go.

There are two parts to Regula. The first is a shell script that generates a Terraform plan in JSON format, ready for consumption by OPA.

The second part is a Rego framework that:

* Merges resource info from planned\_values
and configuration in the terraform plan into a more conveniently accessible format.
* Looks for rules and executes them.
* Creates a report with the results of all rules and a control mapping in the output.

We hope you give it a try and would love to hear what you think. [https://github.com/fugue/regula](https://github.com/fugue/regula)

https://redd.it/eq2s6m
@r_devops

20 years since Y2K

Thought this article might be of interest--it looks back over a couple of big tech incidents and discusses what we've learned: [https://www.transposit.com/blog/2020.01.15-left-pad-heartbleed-and-devops/](https://www.transposit.com/blog/2020.01.15-left-pad-heartbleed-and-devops/)

(full disclosure, a co-worker wrote it.)

https://redd.it/eq3ot9
@r_devops

Deployments sharing helm charts best practices

What are the best practices as far as deployments sharing helm charts?

The company I started working for is using a single huge, monolithic chart for all their deployments (100's) and that strikes me as very wrong.

Equally, having a helm chart for every deployment/repo has the downside of creating difficulties when you want to change the deployment for a subset of microservices that all share a common pattern, which makes using a shared chart attractive.

So in general, what should be done?

https://redd.it/eq0ecx
@r_devops

Spin up temporary site for each pull request

I have been looking for a way to create a temporary environment (azure app service) for my application (aspnetcore + react) for each and every pull request that is made against master, so developers can review the code and testers can test the features before they are actually merged into master and Azure Devops sends the changes towards production.

The reasoning behind this is to make sure we are always able to deploy to production (preferrably automatically) without risking untested features are blocking tested features. I would also like us to be able to use only one pull request, and not first a PR for each feature against dev, then against test and then against master when it is ready for production.

Am I insane?

I can't seem to find anyone that spins up new app services on azure from their ci/cd system. We are using Azure DevOps for build and release pipelines now, everything is hosted on Azure. Any suggestions are appreciated.

https://redd.it/epz3bm
@r_devops

sonar-cxx: flags to prevent a rule to be triggered

Hi.

I was searching for a possibility to deactivate some rules for a particular piece of code when using [sonar-cxx](https://github.com/SonarOpenCommunity/sonar-cxx).

Here is an example. The `cxx:TooLongLine` is a controversial rule that triggers when a line's length is > 160 characters, but I try to abide by it whenever possible. But in some rare cases, it can be troublesome.

In my latest project, I have to compose web pages using pieces of HTML, CSS and SVG pictures in particular, all of this using C++. You guessed it: SVG pictures produce very long `const char *` strings, and there are a few of them.

So yes, one of my header files has plenty of `cxx:TooLongLine` violations, and I'm searching for a way to deactivate the rule, *one line at a time*.

I remember, back when I was coding in Java, that there was a inline flag that allowed to deactivate a rule for a specific piece of code, for example (might be wrong):

```
//@deactivate(java:TheRuleToDeactivate)
```

So my question is: is there a way to do something similar with sonar-cxx?

Thanks a lot for your help.

https://redd.it/eq1a0b
@r_devops

So, how are you guys releasing your artifacts?

Similar to another enquiry I've made in the past about what Artifactory software you are using, but a more general information gathering one this time - how are you releasing artifacts and getting them to your customers?

Our shop isn't a full SaaS (yet), so when we do CI/CD we push changes to our own live/customer environments where we can develop against. Our artifacts strategy at the moment is to release the files on our Jira Board in the announcements page to our respective customers. I want to try and improve this as it's been there since god knows when and it feels like a better process should exist.

Our customers take the artifacts we release and give them to there own QA team who do there own CD process after they've quality checked and raised any tickets we might have missed, followed by pushing them to there own live environment we don't control.

We have a container registry where I've been trying to push changes into our docker image and have our environments refresh that everytime there's a change to our image, but it's just experimental and I want to know how everyone else is doing it.

https://redd.it/epxmjt
@r_devops

Scaling docker container horizontally benefits if on same host

What are the benefits of scaling a service horizontally when they run on the same host? Say two instances of a microservice instead of one.

Wouldn't the resources that could have been used for the single microservice just get split up and used for the second, giving no real benefit. Like instead of having one car go 100km/h now there are two cars each going 50km/h ?

https://redd.it/eq8n66
@r_devops

How to automatically ensure pipeline compliance

So, let's say that we want to ensure that all software pipelines put the code through SAST testing (or any other important step), how do we as DevOps engineers ensure that the pipelines for 100 or 1000+ all confirm to business requirements? What's to stop one developer removing a crucial step in the pipeline and another approving this and it therefore not going noticed for a very long time? or, possibly more likely, what's to stop a developer taking a template pipeline and simply removing a step on the initial pipeline commit?

For context we are currently using gitlab CI but are looking at potentially moving to cloud build, I hope the answer to this is platform agnostic (but assume it won't be)

https://redd.it/epyi34
@r_devops

GuardDuty: The request is rejected because the caller is not authorized to call this API

I have an AWS GuardDuty stack. Inside I have one resource:

IPSet:
Type: "AWS::GuardDuty::IPSet"
Properties:
Activate: True
DetectorId: !Ref Detector
Format: TXT
Location: s3://mybucket/ipset.txt
Name: MyIPSet

I create the bucket:

▶ aws s3 mb s3://mybucket/
make_bucket: mybucket

List stuff in the bucket etc, all works fine.

On deploying the stack:

{
"StackId": "arn:aws:cloudformation:us-east-1:111111111111:stack/test-stack/28801e90-390b-11ea-9d33-0ab1b9b87aaa",
"EventId": "ThreatIntelSet-CREATE_FAILED-2020-01-17T09:25:10.136Z",
"ResourceStatus": "CREATE_FAILED",
"ResourceType": "AWS::GuardDuty::ThreatIntelSet",
"Timestamp": "2020-01-17T09:25:10.136Z",
"ResourceStatusReason": "The request is rejected because the caller is not authorized to call this API. (Service: AmazonGuardDuty; Status Code: 400; Error Code: InternalServerErrorException; Request ID: b70503ba-3598-4f3e-97be-bd6ebaf58b94)",
"StackName": "test-stack",
"ResourceProperties": "{\"Format\":\"TXT\",\"Activate\":\"true\",\"DetectorId\":\"4eb7d968df4f4f7db0be0711b0c027d3\",\"Location\":\"s3://mybucket/threatset.txt\",\"Name\":\"fooorg-audit-ThreatIntelSet\"}",
"PhysicalResourceId": "",
"LogicalResourceId": "ThreatIntelSet"
}

I've seen this answer here in Stack Overflow

[https://stackoverflow.com/questions/48404164/accessdeniedexception-caller-is-not-authorized-to-call-api-using-aws-guardduty/57725109#57725109](https://stackoverflow.com/questions/48404164/accessdeniedexception-caller-is-not-authorized-to-call-api-using-aws-guardduty/57725109#57725109)

But no use. Very frustrated! Any thoughts on what else it could be?

https://redd.it/epy9mp
@r_devops

Does Microsoft have their own implementation of microservices?

[https://en.wikipedia.org/wiki/Microservices#A\_comparison\_of\_platforms](https://en.wikipedia.org/wiki/Microservices#A_comparison_of_platforms) shows two implementations of microservices: Spring Cloud and Kubernetes ecosystem.

Does Microsoft have their own implementation of microservices too? [https://dotnet.microsoft.com/learn/aspnet/microservices-architecture](https://dotnet.microsoft.com/learn/aspnet/microservices-architecture) seems to mean that they can create a microservice by deploying a service inside a docker container. Maybe use Docker Swarm to coordinate multiple containers?services? Is this Microsoft's platform/implementation of microservice architecture?

https://redd.it/eqb22x
@r_devops

Kafka is no longer the best choice thanks to Apache Pulsar

Recently on HackerNews someone asked why I was moving off of Kafka and I wrote a somewhat lengthy comment.

This inspired me to do a presentation at a meetup about how Apache Pulsar has come to replace Kafka and how today there's not really a reason to be on Kafka unless you've invested into it heavily already.

Here is the talk:
https://youtu.be/jLruEmh3ve0?t=130

https://redd.it/eppwrp
@r_devops

Application/Service Inventory Query

Between Dev, Test, and Prod we have a large number of On-Premises servers (Physical and VM). Running various applications like databases, web servers etc.

The trouble is working out what is what. For example, I need to make a change to Customer A's web server, I first need to discover the hostname of the web server.

Now I know in AWS we just query the tags of the instance, easy peasy. But how would we go about this for a physical environment?

Would appreciate some guidance on how this could be acheived.

End result: I want to quickly ask some appliction/service where Customer A's servers are, and filter from there.

https://redd.it/epddoj
@r_devops

What software engineering methods are monitoring tools like DynaTrace using to get such detailed metrics?

Sorry if this is the wrong sub, was thinking about posting it in /r/programming or something similar, but it strikes me as a devops-y question. How do DynaTrace and other monitoring tools get metrics and info such as:

* Request routes with response times and tracing
* JVM metrics
* Memory, CPU, etc metrics of hosts and containers
* DB queries and other database information
* All kinds of other information we use for analysis, alerting, etc.

I've implemented tools like DynaTrace and Prometheus at work, and I appreciate how useful they are, but I'd like to understand more about the software engineering that goes into building tools like these. How do they get these metrics? What methods are they using to format and store them? I know I can use top or free to check mem/cpu, or run jstat to look at JVM metrics if I'm on a Linux host, but how are these monitoring tools doing it and making the data easy to understand?

​

I realize this might seem kind of broad, or might be a "duh" question to some people, but I'd really like to learn more about this. A lot of the monitoring tools I use are almost like a black box/magic to me, they just work and I want to know what's happening at the code level for them to accomplish what they're doing.

https://redd.it/epcbz5
@r_devops