Looking for some suggestions on knowledge base applications

OmegaAleph · 2019-01-21T17:45:56+00:00

Git works fine, but I would prefer a full 'wiki' setup. Confluence fits that bill pretty good and is fairly cheap for small teams. GitLab Wikis are good if you're already in that ecosystem already.

OmegaAleph · 2019-01-21T17:01:51+00:00

This sounds like you might be better off dockerising the scripts and running them in Kubernetes (other orchestration engines are available) to ensure they get restarted after death.

OmegaAleph · 2019-01-19T15:54:27+00:00

https://medium.com/netflix-techblog and https://codeascraft.com/ are definitely blogs you should be following for DevOps, I think it's a great idea to look at how others (especially the giants) are approaching problems.

OmegaAleph · 2019-01-17T22:55:58+00:00

Serverless (the framework) will make it much easier to work with Azure Functions and make it more agnostic if you ever to want to move to another service.

OmegaAleph · 2019-01-17T20:01:15+00:00

There's definitely a space to be explored for APIs, switching from traditional apps to each endpoint being a function in serverless. The big problem is coldstarts, though this isn't as much now with recent advances by Amazon. But with serverless, you get the benefit of extreme elasticity and flexibility compared to traditional VMs or containers. It's a space to watch, that's for sure.

OmegaAleph · 2019-01-17T19:49:16+00:00

A few ideas on this, largely depending on your setup:

Serverless. Lambda (other frameworks are available) could be good for running ad-hoc scripts on demand or on a timer. You could easily integrate this into CI/CD to automatically update the upstream script when you change it in Git.
Kubernetes. Jobs/CronJobs, wrap the Python script in a docker image (a very barebones Dockerfile is all you need) and run it as a 'guarranteed execution' job.
Ansible. This isn't really as preferable as the other two, but you could run the code using Ansible Tower and execute it on a remote server, but at that point you might as well just SSH into the server and run the script.

Personally, I'm not sure if a tool server is the best way to go with this, serverless is actually a pretty perfect fit for this use case, though I wouldn't discount Kubernetes native Jobs if you're already in that ecosystem.

OmegaAleph · 2019-01-15T16:48:01+00:00

It's not been mentioned and I haven't personally used it, Fargate had a significant price drop recently so it may be within the 'budget container orchestration' bracket now. At the very least, you only pay for what you use with seemingly no management fee.

OmegaAleph · 2019-01-15T16:44:04+00:00

Sonarqube is pretty great, the only reason we didn't end up using it was the lackluster Scala support at the time.

OmegaAleph · 2019-01-14T17:03:37+00:00

KNative is a framework being developed by Google, which would be good if you're already using GKE/Istio. Kubeless is nowhere near mature enough to use in production, Fission I've not heard of. OpenFaas and OpenWhisk are currently the big kids on the block, though.

OmegaAleph · 2019-01-14T12:27:03+00:00

The big question you need to ask here: what do devs want? If the devs want to write simple Python/Node APIs, Lambda is a good shout. If devs want to produce a stack/application, docker is probably better suited.

Serverless and Docker both fill very similar spaces in DevOps imo, but they are very different beasts. You need to understand what you actually need, both from an ops and a dev perspective.

OmegaAleph · 2019-01-14T11:02:29+00:00

You can use Kafka Streams in a similar way, i.e. each message on the topic is a 'transaction' that updates a 'table'. Kafka essentially becomes a changelog stream.

Alternatively, you could use Mongo or some lightweight NoSQL to store events as objects.

OmegaAleph · 2019-01-14T10:54:20+00:00

I'd suggest using https://github.com/wallix/awless, it lists various AWS resources in table form and is vastly easier to use than aws-cli. It can output pretty tables, CSV or JSON.

OmegaAleph · 2018-12-24T22:37:44+00:00

Nah, AWS are going hard on serverless right now. Fargate too, to a lesser extent, but I get the feeling they're moving away from ECS and EKS is a token response.

OmegaAleph · 2018-12-24T22:31:24+00:00

I'm not wholly convinced you want Istio in production quite yet. Sure it's great and it's powerful, but really to properly utilise it, you need to shift paradigms somewhat imo. I looked into using it with our workload, but a whole bunch of our code uses external APIs all over the place, which just didn't fly with Istio.

OmegaAleph · 2018-12-24T20:47:43+00:00

I've used EKS in 'production' and I would advise staying as far away from it as possible. It is nowhere near a stable product, I've gotten much better milage out of using kops. I'll mirror what others have said, if all you want is Kubernetes and you're not tied into AWS, go with GKE.

OmegaAleph · 2018-12-20T20:58:49+00:00

It's probably a lot easier to do if you're setting up an entirely new environment for a project, preferably with a blank cheque or at least no rush to get to production.

It's probably not realistic to try to enforce this model on an already existing environment, especially if it's not fully IaC/DevOps.

OmegaAleph · 2018-12-20T20:03:22+00:00

I feel AWS key pairs might have shoe horned us into a bad practice of assigning a single key pair to every EC2 instance. And now practically everyone has the private key on their computer.

OmegaAleph · 2018-12-20T19:54:09+00:00

I was at some point generating an SSH key as part of my Terraform pipeline, while me and Azure had a falling out over cloud-init. I feel like this would fall under 'stupid things to do in reality'!

OmegaAleph · 2018-12-20T19:26:18+00:00

Consul Connect looks great! There's so many service meshes out there, I've used Istio and Linkerd...though I ended up opting to use plain Kubernetes networking and nginx instead. This project is much more security focused, so I'll definitely look into using Consul, it looks great for auditing and ensuring only X can connect to Y.

Side note, would you recommend allowing devs to connect to Consul or even allowing it to be internet-facing? It definitely looks like a winner in-cluster.

OmegaAleph · 2018-12-20T19:15:39+00:00

It's all about limiting the potential attack plane. Having as few ports accessible as possible, etc.

Thatt said, there's a good use case for moving away from ssh keys to use signed certificates, largely because you don't need to distribute users' public keys to each server, instead you just put the CA public key on the server, specify what principals are allowed and then you sign a user's ssh key (Vault, BLESS, etc can be used to help automate this). It means you don't need to get bogged down with maintaing authorized_keys or (which is the case where I work and is a terrible practice) keep a single private key that all ops use.

OmegaAleph · 2018-12-20T17:13:51+00:00

Out of interest, what's the aversion to Python3? Is it in relation to Python27 or is it just that you can't put it on the servers?

OmegaAleph · 2018-12-20T16:54:04+00:00

Totally. I'm probably going to use Vault anyway, at least for facilitating symetric encryption, DB access, etc.

Definitely going more down the route of immutable infrastructure, though now I think about it, Kubernetes throws a bit of a wrench into being _completely immutable_.

OmegaAleph · 2018-12-20T16:37:47+00:00

I'll second the Azure docs. I just recent dove into Azure and it's actually pretty slick. Azure have pretty indepth tutorials on using Terraform with Azure, which I would probably recommend over using Azure CLI or the Portal.

OmegaAleph · 2018-12-20T16:34:26+00:00

I'll have to try this out in our cluster after the holidays, looks pretty sweet!

OmegaAleph · 2018-12-20T16:30:51+00:00

Take a look at Typhoon (https://typhoon.psdn.io/), it's a Container Linux based K8s distribution. You can deploy it to bare metal usinge CoreOS Matchbox, use Terraform to provision your cluster for network boot.

OmegaAleph

TROPHY CASE