Export your public key:
keybase pgp export > keybase-public.key
Export your private key:
keybase pgp export --secret > keybase-private.key
Export your public key:
keybase pgp export > keybase-public.key
Export your private key:
keybase pgp export --secret > keybase-private.key
Just documenting docs, articles, and discussion related to gRPC and load balancing.
https://github.com/grpc/grpc/blob/master/doc/load-balancing.md
Seems gRPC prefers thin client-side load balancing where a client gets a list of connected clients and a load balancing policy from a "load balancer" and then performs client-side load balancing based on the information. However, this could be useful for traditional load banaling approaches in clound deployments.
https://groups.google.com/forum/#!topic/grpc-io/8s7UHY_Q1po
gRPC "works" in AWS. That is, you can run gRPC services on EC2 nodes and have them connect to other nodes, and everything is fine. If you are using AWS for easy access to hardware then all is fine. What doesn't work is ELB (aka CLB), and ALBs. Neither of these support HTTP/2 (h2c) in a way that gRPC needs.
conn, err := grpc.Dial( | |
s.rpcSocketPath, | |
grpc.WithInsecure(), | |
grpc.WithDialer(func(addr string, timeout time.Duration) (net.Conn, error) { | |
return net.DialTimeout("unix", addr, timeout) | |
})) | |
if err != nil { | |
log.Fatalf("did not connect: %v", err) | |
} | |
defer conn.Close() |
Run this in order to backup all you k8s cluster data. It will be saved in a folder bkp. To restore the cluster, you can run kubectl apply -f bkp
.
Please note: this recovers all resources correctly, including dynamically generated PV's. However, it will not recover ELB endpoints. You will need to update any DNS entries manually, and manually remove the old ELB's.
Please note: This has not been tested with all resource types. Supported resource types include:
package main | |
import ( | |
"io" | |
"log" | |
"net" | |
"time" | |
) | |
func reader(r io.Reader) { |
Beyond the read-only resources that existed in Terraform before data resources were an official feature, I'd like to make room for a new pattern for re-usable modules where they accept only the minimum set of ids they need as variables and look up other data via data sources.
Here's a motivating example:
variable "aws_subnet_id" {
description = "Id of the subnet where the EC2 instance will be created"
}
Currently, there is an explosion of tools that aim to manage secrets for automated, cloud native infrastructure management. Daniel Somerfield did some work classifying the various approaches, but (as far as I know) no one has made a recent effort to summarize the various tools.
This is an attempt to give a quick overview of what can be found out there. The list is alphabetical. There will be tools that are missing, and some of the facts might be wrong--I welcome your corrections. For the purpose, I can be reached via @maxvt on Twitter, or just leave me a comment here.
There is a companion feature matrix of various tools. Comments are welcome in the same manner.
resource "aws_db_instance" "core" { | |
username = "postgres" | |
password = "changeme" | |
... | |
} | |
resource "null_resource" "master_password" { | |
triggers { | |
db_host = "${aws_db_instance.address}" | |
} |
The idea of "state" is the lynchpin of Terraform, and yet Terraform's workflow is fraught with gotchas that can lead to the loss or destruction of state. This doc is a set of notes about issues I've encountered, what caused them, and in many cases ideas about how to improve Terraform to avoid or reduce the chances of them.
Each of these scenarios has occured at least within my team. Each time one of these occurs it erodes people's confidence in Terraform, giving it a reputation for being fragile and unforgiving of errors. This this document is not written just to criticize but rather to identify ways in which the situation could be improved.