Wie man Docker Container innerhalb eines benutzerdefinierten Bridge Netzwerks kommunizieren lässt
Secrets management in the context of PaaS is one of the most important topics and a primary objective to guarantee. One use case leads us to answer the question: How to manage and securely provide secrets to each container at runtime? Before landing on this discussion, let us underline the problem encounter with secrets in PaaS firstly.
When creating a VM in vCloud Director (vCD), vCD automatically assigns a MAC address. To ensure that the MAC address is unique within the environment the vCD uses the instance ID of the vCD installation to define the MAC address range. If you have multiple vCD instances you might use different IDs for your installations to avoid duplicate MAC addresses.
Most people probably see good passwords as a cumbersome necessity. They come attached with a seemingly ever-changing set of rules that force us to create intricate text strings that are usually a pain memorize.
In this post I will try to highlight the joy of good passwords by assigning them a monetary value albeit admittedly an imperfect one. I encourage everybody not to see password creation as a tedium but instead to enjoy the financial catastrophe we inflict to an imaginary attacker foolish enough to attempt cracking our password. In addition I will present a scheme that allows the creation of good passwords that are also easy to remember.
NSX-T supports Multi-TEP just like NSX-V. But this feature was limited to ESXi hosts and it was not supported for Edge Nodes. Since NSX-T version 2.4 Multi-TEP is supported for Edge Nodes as well, which optimizes the North-South network performance.
Starting with NSX-T 2.4 the Multi-TEP was supported but not recommend from reference design guide perspective. The recommendation was added after the reference design guide was updated for NSX-T 2.5. Since then a deployment with a single NVDS vor VLAN and Overlay transport zones combined with Multi-TEP for ESXi and Edge Nodes is recommended.