Ansible Rewrite

[sudomann]

Description of the Change

Rewritten for peers to be able to discover each other within the cluster and communicate within a given namespace. A service is also defined to expose torii-port to another specified namespace (has been preset to namespace: default).

Benefits

Ansible configuration for Kubernetes that works and is flexible to customize via variables without breaking functionality.
Configuration follows good semantics, and allow easy deployment with minimal effort.

Possible Drawbacks

None

Usage Examples or Tests [optional]

Alternate Designs [optional]

[sudomann]

Tested to work on GKE, and probably also works with Amazon EKS. Certainly does not work with baremetal Kubernetes clusters.

[sudomann]

Would be great if someone could help out in setting appropriate resource limits. I have no idea what iroha needs and lack expertise to measure/analyze.

[baydarich]

@sudomann You were asking me about improving security handling. Deleting files with private keys from a deployment host after the process is finished sounds like a good idea, but be sure to backup them somewhere in a safe place.

I don't understand why there are private and public keys embedded directly in configuration files, can you clarify a bit?

[sudomann]

@baydarich When Ansible generates keys for each peer, they are first recorded into a csv file.

1. For lack of a better alternative, I improved upon the existing kubernetes setup, which preserves each peer as its own unique entity with fixed persistent storage. The csv file is handy for subsequent tasks such as registering all peers in the genesis.block file, since the peer's hostname and public key are extracted from it.

2. Later on in the process, the public and private keys of each peer are extracted from that csv file to generate a yml resource file for cluster secrets. The keys are encoded in base64 (requirement of Kubernetes) but can be very easily reverted to readable hex. This yml file is used to create all the secrets at once with a single command.

3. Before each pod hosting a peer is started, these keys are mounted from secrets and copied to appropriate containers.

As I understand, there is no further use in knowing/keeping the private keys beyond that once all the peers have them mounted. For potential debugging purposes however, I thought it made sense to have files showing that the role was working as intended. e.g verifying using the csv file that the peers were assigned the right combination of hostname and public key when added in the genesis.block (in the same order), along with the mounted secrets (in the same order).

I've thought about changing the Ansible steps to instead add a peer to the genesis.block file with its hostname, and create its secret as they are generated, but this is much more annoying for a developer to debug, with nothing but a trail of scattered stdout text to piece together.

[bakhtin]

Thanks for the contribution. I skimmed through the code and overall it looks good. But we need some time to actually test the new playbook. Based on the test results I'll be able to give a proper feedback.