toredash

Managed a fairly large matomo site in the past. Using queue plugin (https://plugins.matomo.org/QueuedTracking) with Redis Cluster really improves the situation. We actually built a custom plugin with Nginx + Lua to avoid PHP altogether for the tracking part. Scaling ingestion then wasn't the problem, draining the queue was

Comment · 6 months ago

Is there any DNS based software to do block/allow? Kinda lika what's present in CiliumNetworkPolicies in Kubernetes networking?

Comment · 11 months ago

I often find myself trying to tell people that KISS is a good thing. If something is somewhat complex it will be really complex after a few years and a few rotations of personnel.

Comment · 1 year ago

If the image repositories were AZ bound resources, that would make the CI build process more efficient.

Or, if the resources that CI build is utilizing within the image (after the image is pulled and started) is AZ bound, then yes the build process would be improved since the CI build would fetch AZ local resources, rather than crossing the AZ boundary

Comment · 1 year ago

> If you have the setup on 3 AZs how would you route traffic only to the AZ where your RDS resides?

So specifically for RDS, AWS will provide two endpoint for the client application: A writer and a reader endpoint. Similar to this: mydbcluster.cluster-c7tj4example.us-east-1.rds.amazonaws.com : Writer endpoint mydbcluster.cluster-ro-c7tj4example.us-east-1.rds.amazonaws.com : Reader endpoint (notice -ro part).

The writer endpoint will always resolve to the active master, which is what the client application is configured to use, and thats the hostname my lookup service will use as input to determine the current location of the Writer instance.

My solution works only for hostnames that returns a single IP address, so it won't work for the Reader endpoints. As I wrote in the repository, a requirement for this is that "The FQDN needs to return a single A record for the external resource".

Comment · 1 year ago

> And I don't understand how a tool like this fits into formal risk analysis and where it presents an optimum solution for those risks.

Seems it does not fit your risk analysis?

Comment · 1 year ago

> Most people should start with a single-zone setup and just accept that there's a risk associated with zone failure. If you have a single-zone setup, you have a node group in that one zone, you have the managed database in the same zone, and you're done.

I don't disagree, but there is one issue with this approach and that is that RDS is a multi AZ service by itself. That means that when a maintenance event occur on your insaance, AWS will start a new instance in a new zone, and fail over to that one.

You could of course manually failover RDS afterwards to your primary zone. Not sure if that is better than manually scaling up a node pool if a zone fails.

> So you are presuming that, when RDS automatically fails over to zone b to account for zone a failure, that you will certainly be able to scale up a full scale production environment in zone b as well, in spite of nearly every other AWS customer attempting more or less the same strategy;

Thats up to the user to decide via the Kyverno policy. We used the preferredDuringSchedulingIgnoredDuringExecution affinity setting to instruct the scheduler to attempt to schedule the pods in the optimal zone.

I believe the only way to be 100% sure that you have compute capacity available in your AWS account is the use EC2 On-Demand Capacity Reservations (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capa...). If your current zone is at full capacity, and for some reason the nodes your VMs are running on dies, that capacity is lost, and you wont get it back either.

Comment · 1 year ago

Are you thinking about already-cached container images on the host level ? Not sure how AZP fits in here?

Since you mentioned it, what I've done before when it comes to improving CI builds, is to use karpenter + local SSD mounts with very large instance types in an idle timeout of ~1h. This allowed us to have very performant build machines at a low cost. The first build of the day took a while to get going, but for the price-benefit perspective it was great.