|
| 1 | +### Exposing External Services |
| 2 | + |
| 3 | +This readme intends to give you the information required to run stack updates that deploy the necessary infrastructure to allow non-http services to be exposed outside our clusters. The following parameter addition is required to deploy even if you are not exposing any services: |
| 4 | + |
| 5 | +``` |
| 6 | + network_config: |
| 7 | + allocation_pool: [{"start": "10.3.1.2", "end": "10.3.1.100"}] |
| 8 | + cidr: "10.3.1.0/24" |
| 9 | + dns: [ "8.8.4.4" ] |
| 10 | + gateway: "10.3.1.102" |
| 11 | + bastion_ip: "10.3.1.101" |
| 12 | + service_subnet: "10.3.1.240/29" # This is the new addition. It's the subnet to be used for service_ip on services. Must be within internal network range and not conflict with allocation pool. |
| 13 | +``` |
| 14 | + |
| 15 | +The parameter used to deploy the actual external_services infrastructure is ```external_services_config``` this can be hashed out if not required and it will not try to create the external services resource at the top level. If you do want to use an external service then the following block is an example: |
| 16 | + |
| 17 | +``` |
| 18 | + external_services_config: |
| 19 | + - service_ip: 10.3.1.240 # Sets the internal IP of the port that a floating IP will be associated to |
| 20 | + floating_network: "Internet" # Will create a floating IP on the specified network and associate it to the service_ip port. |
| 21 | + proto: tcp or udp # Used in the security rule thats created to allow access. Should match the service protocol. |
| 22 | + port: 3306 # Used in the security rule thats created to allow access. Should match the service port. |
| 23 | + allowed_sources: sources allowed to hit service e.g. 0.0.0.0/0 # Used in the security rule thats created to allow access |
| 24 | +``` |
| 25 | +> [!WARNING] |
| 26 | +> Always do a stack show before attempting to update the external_services to ensure you pass in all of the existing json blocks. |
| 27 | +
|
| 28 | + |
| 29 | +It's important to note that the blocks are a list of json objects. The order of them matters, if you are updating a cluster to add extra services you MUST keep them in the correct order otherwise the already exposed services will be destroyed. An example of deploying two external services would be: |
| 30 | + |
| 31 | +``` |
| 32 | + external_services_config: |
| 33 | + - service_ip: 10.3.1.240 |
| 34 | + floating_network: "Internet" |
| 35 | + proto: tcp |
| 36 | + port: 3306 |
| 37 | + allowed_sources: 0.0.0.0/0 |
| 38 | + - service_ip: 10.3.1.241 |
| 39 | + floating_network: "Internet" |
| 40 | + proto: tcp |
| 41 | + port: 3307 |
| 42 | + allowed_sources: 0.0.0.0/0 |
| 43 | +``` |
| 44 | + |
| 45 | +The above will deploy two floating IPs on the internet, one mapped to the internal IP of 10.3.1.240 and the other mapped to the internal IP of 10.3.1.241. It will also add two security rules to all nodes allowing access to 3307 and 3306 from all sources. While this may seem insecure IPtables rules within the cluster will ensure you can only hit the relevant service on the relevant IP once they have been exposed. |
| 46 | + |
| 47 | +What if a customer wants to expose multiple services on a single IP? Well let's say the customer wants one internet IP and would like to expose tcp 3306 and udp 53 on it. The way this would be done is: |
| 48 | + |
| 49 | +``` |
| 50 | + external_services_config: |
| 51 | + - service_ip: 10.3.1.240 |
| 52 | + floating_network: "Internet" |
| 53 | + proto: tcp |
| 54 | + port: 3306 |
| 55 | + allowed_sources: 0.0.0.0/0 |
| 56 | + - port_ip_deploy: false |
| 57 | + proto: udp |
| 58 | + port: 53 |
| 59 | + allowed_sources: 0.0.0.0/0 |
| 60 | +``` |
| 61 | + |
| 62 | +In the above ```port_ip_deploy: false``` specifies to not create a floating IP or internal IP so the second block is only creating a security rule allowing access to the nodes on port 53 from all sources. You could then expose two services on 10.3.1.240 from inside the cluster and each would be reachable on the same floating IP. |
| 63 | + |
| 64 | +To remove a resource you would simply change the block it exists in to the following: |
| 65 | + |
| 66 | +``` |
| 67 | + external_services_config: |
| 68 | + - port_ip_deploy: false |
| 69 | + sec_rule_deploy: false |
| 70 | + - port_ip_deploy: false |
| 71 | + proto: udp |
| 72 | + port: 53 |
| 73 | + allowed_sources: 0.0.0.0/0 |
| 74 | +``` |
| 75 | + |
| 76 | +In the above the first block used to create an internal IP of 10.3.1.240, map a floating IP from the internet to it and create a security rule allowing access on 3306. ```port_ip_deploy: false``` and ```sec_rule_deploy: false``` will ensure that when you update the stack this resource block will be evaluated and all resources previously related to it will be destroyed. |
| 77 | + |
| 78 | +If you wanted to change a floating IP to a different network you cannot simply overwrite the ```floating_network``` parameter and update. You first need to destroy the resources from the block in an update and then specify a new network and update. The stages would be: |
| 79 | + |
| 80 | +``` |
| 81 | + external_services_config: |
| 82 | + - service_ip: 10.3.1.240 |
| 83 | + floating_network: "Internet" |
| 84 | + proto: tcp |
| 85 | + port: 3306 |
| 86 | + allowed_sources: 0.0.0.0/0 |
| 87 | +``` |
| 88 | + |
| 89 | +Original deployment config. Customer then asks for the 10.3.1.240 to be accessible on HSCN rather than the internet: |
| 90 | + |
| 91 | +``` |
| 92 | + external_services_config: |
| 93 | + - port_ip_deploy: false |
| 94 | + sec_rule_deploy: false |
| 95 | +``` |
| 96 | + |
| 97 | +Update is run, destroying the resources. |
| 98 | + |
| 99 | +``` |
| 100 | + external_services_config: |
| 101 | + - service_ip: 10.3.1.240 |
| 102 | + floating_network: "HSCN" |
| 103 | + proto: tcp |
| 104 | + port: 3306 |
| 105 | + allowed_sources: 0.0.0.0/0 |
| 106 | +``` |
| 107 | + |
| 108 | +Final update is run re-creating the resources. |
| 109 | + |
| 110 | +Finally, the best way to go about updating these parameters is to create your own yaml file containing the block (in this example it's service-update.yml) and running the following: |
| 111 | + |
| 112 | +``` |
| 113 | +openstack stack update <stack> --existing -e service-update.yml |
| 114 | +``` |
0 commit comments