544 karma · joined August 2, 2012
If you want to drain 3 nodes as fast as possible it's best to start by cordoning all 3 of them and after that run drain on each respectively. This will cause minimal unnecessary interruption of pods. What we want to avoid is that new pods start on nodes that we soon want to remove/drain.
Audit logs are in many cases disabled by default (RDS, S3, OpenSearch, ELB).
S3 does not require TLS requests by default. ECR does not have image scanning enabled by default.
Also new accounts almost all regions enabled and a default VPC in each (and subnets, route tables, security groups, internet gateway, dhcp option set). Unused VPCs are not recommended to keep around but I suppose it makes onboarding easier.
[1] https://kubernetes.io/docs/tasks/administer-cluster/nodeloca...
rankmirrors test the time to download core.db from each mirror. Basically this:
curl -s -m 1 -w "%{time_total} %{http_code}" -o/dev/null https://cloudflaremirrors.com/archlinux/core/os/x86_64/core.db.tar.gz
The results vary a lot sometimes cloudflare mirrors is the fastest, sometimes it's the slowest. Getting anything between 0.07 and 0.30 $ rankmirrors -t ./ml
Querying servers. This may take some time...
* * * * * *
Servers sorted by time (seconds):
https://ftp.lysator.liu.se/pub/archlinux/$repo/os/$arch : 0.113249
https://ftp.acc.umu.se/mirror/archlinux/$repo/os/$arch : 0.120371
https://mirror.osbeck.com/archlinux/$repo/os/$arch : 0.127601
https://archlinux.dynamict.se/$repo/os/$arch : 0.180493
https://ftp.myrveln.se/pub/linux/archlinux/$repo/os/$arch : 0.248406
https://cloudflaremirrors.com/archlinux/$repo/os/$arch : 0.302824
$ rankmirrors -t ./ml
Querying servers. This may take some time...
* * * * * *
Servers sorted by time (seconds):
https://cloudflaremirrors.com/archlinux/$repo/os/$arch : 0.070069
https://mirror.osbeck.com/archlinux/$repo/os/$arch : 0.081506
https://ftp.lysator.liu.se/pub/archlinux/$repo/os/$arch : 0.098763
https://archlinux.dynamict.se/$repo/os/$arch : 0.125846
https://ftp.acc.umu.se/mirror/archlinux/$repo/os/$arch : 0.127948
https://ftp.myrveln.se/pub/linux/archlinux/$repo/os/$arch : 0.136529 jq -c -r '.[] | .id_str'
# Can be rewritten to
jq -r '.[].id_str'
jq -c -r '.[] | .id_str' | head -10 | tail -1
# Can be rewritten to
jq -r '.[9].id_str'Every company and team operate under different circumstances that might not be in their control. It's a company effort, not only engineering, to get in to a position where using public cloud or buy it of the shelf products is possible.
Having both skilled legal and sales + business colleagues is key but a luxury in these situations.
After the RDS instance is created we need to manually create credentials so that Vault gains access to control it though, this is our mission to automate soon.
With credentials in place teams need to maintain schema creation and migrations themselves. We provide wrapper scripts go gain access with Vault credentials mysql shell or Perconas pt-inline-schema-change. Some teams create pre-deploy jobs or init-containers so that their service can run migrations automatically.
Resonates very well with me, working at a scale up in a "platform team".
Business wise we're set to out engineer competition. Biggest challenges are definitely to get engineers on board on training and transitioning into new "cool" technology. Should we help highly skilled advanced teams run fast or focus on getting everyone on board the cloud native train?
I don't feel comfortable asking this question. Many of the people I interview are "headhunted" into an interview by an talent acquisition team. Are they even looking for a new job?