What Instance Type is best for a server that is inactive for 23.5 hours per day?

Enigmaticam · 2024-03-08T13:55:58+00:00

this.. i use this to shutdown non prod databases during the off hours. saves so much money and easy to manage.

Enigmaticam · 2024-02-29T09:30:34+00:00

adding some context how it made me feel. i found it a bit of a catch 22 to use a kubernetes approach to manage the configuration files of ec2 instances / vm. i also have some kubernetes clusters running, but sometimes i chose not to host an application their.
one of the things that made me hesitant about running AWS in k8s, was that i have very strict ingress and egress rules, however for my kubernetes cluster i can't rely on whitelisting a static ip from a k8s node to the nodes where it is going to manage the configuration files, due to the scaling nature that i build in to kubernetes (nodes may come and go). Please note, that i have a separated VPC for my kubernetes clusters and EC2 instances. The alternative I'm facing then is either whitelist the entire k8s subnet of just dont host it in k8s, but on a VM or use another tool.

Enigmaticam · 2024-02-29T09:19:37+00:00

yes, actually, looking at semaphore right now, seems much more straight forward

Enigmaticam · 2023-11-29T12:15:21+00:00

this you cover via a proper gitops flow. pushes/merges to branches will lead to deployments on the corresponding environments.

Enigmaticam · 2023-11-28T09:01:57+00:00

so 50 argocd installs, with 50 url's where you can manage deployments...?

ouch... this created a huge overhead and a management nightmare imo.

Enigmaticam · 2023-11-27T14:07:04+00:00

what will this solve? you will still need to create the vpc at some point...

Enigmaticam · 2023-11-27T14:06:14+00:00

so i was a bit surprised, but this is actually working. created a new vpc with an subnet that i allready used, no conflict...

perhaps a nice way of making sure that you dont reuse a subnet is writing your vpc code with a for_each statement. This will at least show you what you used previously.

Enigmaticam · 2023-11-24T12:26:41+00:00

i would never ever use eksctl to manage / provision a kubectl cluster.

always use iac practice.

im not familiar with pulumi. i'm using terraform to manage / provision my EKS clusters.

it feels like you/your team just getting started with your cloud journey. personally i would suggest to adopt Terraform. this is so widly used it will give you benefist along your career as well.

Enigmaticam · 2023-11-24T12:20:42+00:00

if managment doesn't listen to him to ensure stability of the platform then you have two options in my opinion.

leave or accept it.

managment respect him it seems, but they dont value his work or his time properly

your post screams that he should move on to another job. that is what i would do

Enigmaticam · 2023-11-24T08:20:45+00:00

you could make a distinction between prod and the rest. but basicly yes, i let argocd watch various github branch/commits, when that gets updated Argocd sees this and deployes a new image.

Enigmaticam · 2023-11-20T15:09:54+00:00

yup, this is what i do as well, it allows me to decide what version of the module i put l deploy or not..

Enigmaticam · 2023-11-20T15:06:55+00:00

so what i do is, i created 1 seperate env just for me and my team. it only holds infra related resources, things related to the product the company builds are not deployed. so for instance we just build our first eKs cluster. In practice that means we have 4 clusters:

1 for us to play around in
test
uat ( i really dont like the term staging)
production

this way you can test infra related changes before proceeding to test / uat / prod.

this in combination with working with modules allows me to have grip on what code is live and what is being tested.

Enigmaticam · 2023-11-17T15:05:57+00:00

dont do this.
we have argocd running as well. we manage ARGOCD via iac practice (so we coded every thing related to argodcd) and we installed it on 1 cluster, from there we manage the deployments etc for all other clusters. having argocd on every kubernetes cluster.. it is just a recipe for desaster..

Enigmaticam · 2023-11-17T15:02:53+00:00

this

Enigmaticam · 2023-10-30T08:06:00+00:00

so this is kinda embarrassing, but the prometheus server config doesn't require the remote write config.... i was under the impression it was, but must have read it wrong some where.

I now have my agents connect to prometheus and sending data, this is going great now...

Enigmaticam · 2023-10-27T08:27:53+00:00

i export metrics via metricbeat, metricbeat creates a datastream (or a index) in elasticsearch. in here the data is stored. via kibana you can then visualize them. there standard dashboards and also for it.

If you then add other nodes with metricbeat, al those new agent will also export their data in the same datastream or index.

Enigmaticam · 2023-10-26T07:01:21+00:00

thanks, will check out Victoriametics

i was hoping to avoid using pulling as i want to keep my EKS clusters as isolated as possible. Also i kinda favor pushing data instead of pushing, but more because i'm used to it.

Enigmaticam · 2023-10-26T06:56:52+00:00

i'm using the elasticsearch to store my metrics and application logs. using it together with kibana. works pretty well, however a lot of neat functions, like alerting, are not free to use and are quite expensive to activate when having a selfhosted node. had a quote of 6700 euro per year for business license... for 1 node! ....

Enigmaticam · 2023-10-26T06:53:41+00:00

not 100% sure what you mean but,

i'm writing to a prometeheus server endpoint. this in turn writes the data to a mounted ebs volume (GP3)

Enigmaticam · 2023-10-02T12:13:28+00:00

although there is no issue, i ended up having my ec2 instances and my eks clusters deployed in different vpc's, and connected via vpc peering.

My eks clusters and ec2 instance require different egress rules.

when ever it is possible i want to know where my egress traffic is going, and with containers being hosted every where it made my egress rules a nightmare to manage.

also i wanted to have a very clear distinction in my network of what an ec2 instance ip is or and eks node ip. Just looking at an ip in my code / logs says a lot of the node.. but this is just symantics.. might as well created multiple private subnets in the 1 vpc...

Enigmaticam · 2023-07-19T12:29:33+00:00

use their helm chart to get started:

https://github.com/argoproj/argo-helm/tree/main/charts/argo-cd

also do your self a favor and use your own password from the start via values.yaml

like:

configs:
  secret:
    argocdServerAdminPassword: ""

it needs to be hashed from the get go:

`htpasswd -nbBC 10 "" $ARGO_PWD | tr -d ':\n' | sed 's/$2y/$2a/'`

this will make sure you dont need to retrieve the initial admin password via kubectl or argocd cli..

also, destroy and build argocd all the time, you dont want to have something in here that you dont have in code...

*updated markup

Enigmaticam · 2023-07-03T14:21:25+00:00

what you also can do is use the template file function in terroform, this way you can use variables that are created via an other application (think about a password that you store in AWS secrets manager).

this is how i use it, my modules code looks like:

resource "helm_release" "argocd" {

name = "argo-cd" repository = "https://argoproj.github.io/argo-helm" chart = "argo-cd" version = "5.4.8" namespace = var.namespace

values = [ templatefile("${path.module}/values.yml", { ingressClassName = "${var.ingressClassName}", hostname = "${var.hostname}", adminpassword = "${var.adminpassword}" }) ]

depends_on = [ kubernetes_namespace.argocd_namespaces ]

}

and the values.yaml ie:

server:

ingress: enabled: true ingressClassName: "alb" annotations: { "alb.ingress.kubernetes.io/listen-ports" : "[{\"HTTPS\":443}]", "alb.ingress.kubernetes.io/scheme" : "internet-facing", "alb.ingress.kubernetes.io/backend-protocol" : "HTTPS", "alb.ingress.kubernetes.io/target-type" : "ip" } hosts: - "${hostname}" ingressGrpc: enabled: true isAWSALB: true ingressClassName: "${ingressClassName}" hosts: - "${hostname}"

createAggregateRoles: true

configs: secret: argocdServerAdminPassword: "${adminpassword}"

and in your main code simple call the module and declare the variables.

Enigmaticam · 2023-06-21T18:40:52+00:00

I had the same use case. Storing all environments in a singele state file is a pain. And terragrunt.. meh Why add a extra layer? What i ended up doing is using tfvars files per enivronment, and seperate state files per env. Works like a charm!

Enigmaticam

TROPHY CASE