Skip to content

Commit 15b5642

Browse files
himeshsiriwardanahimeshsiriwardana
committed
added a tabbed view for clustering configurations
1 parent 410f1f8 commit 15b5642

File tree

1 file changed

+102
-94
lines changed

1 file changed

+102
-94
lines changed

‎en/identity-server/next/docs/deploy/deployment-guide.md‎

Lines changed: 102 additions & 94 deletions
Original file line numberDiff line numberDiff line change
@@ -160,7 +160,7 @@ The following configurations need to be done in both the WSO2 Identity Server no
160160
`<IS_HOME>/repository/conf/deployment.toml` file.
161161

162162
The simplest is the well-known address (WKA) based clustering method. It only suites where all the nodes are deployed on machines having static IP addresses. <!--For more information, see [About Membership Schemes]({{base_path}}/deploy/clustering-overview/#about-membership-schemes).--> Configurations for each membership scheme are listed below.
163-
163+
164164
=== "WKA scheme"
165165

166166
Edit the `<IS_HOME>/repository/conf/deployment.toml` file to add the following configurations.
@@ -184,40 +184,44 @@ The following configurations need to be done in both the WSO2 Identity Server no
184184
=== "EC2"
185185

186186
1. Create a working AWS ECS Cluster with EC2 launch type. Note the following when creating a cluster.
187-
- Select the `EC2 instance` launch type.
188-
- Note the `name` and `VPC CIDR block` of the cluster, as you will require them later for configurations.
189-
- Ensure that the `Container instance IAM role` that you assign to the ECS cluster has the following permission policy attached.
190-
```
191-
{ "Version": "2012-10-17",
192-
"Statement":
187+
188+
- Select the `EC2 instance` launch type.
189+
- Note the `name` and `VPC CIDR block` of the cluster, as you will require them later for configurations.
190+
- Ensure that the `Container instance IAM role` that you assign to the ECS cluster has the following permission policy attached.
191+
192+
```json
193+
{ "Version": "2012-10-17",
194+
"Statement":
195+
[
196+
{
197+
"Effect": "Allow",
198+
"Action":
193199
[
194-
{
195-
"Effect": "Allow",
196-
"Action":
197-
[
198-
"ec2:DescribeAvailabilityZones",
199-
"ec2:DescribeInstances"
200-
],
201-
"Resource": [ "*" ]
202-
}
203-
]
204-
}
205-
206-
```
207-
- Make sure that the security group of the cluster instances has an inbound rule to allow incoming traffic on the Hazelcast default port range `(5701 - 5708)`. It is advised to restrict access to instances in the same security group for this inbound rule.
208-
209-
1. Create a `deployment.toml` file in a preferred directory and add the following configurations.
210-
```
211-
[clustering]
212-
membership_scheme = "aws-ecs"
213-
214-
[clustering.properties]
215-
region = "us-east-1"
216-
clusterName = "ECS-IS-CLUSTER"
217-
hostHeader = "ec2"
218-
vpcCidrBlock = "10.0.*.*"
219-
tagValue = "a_tag_value"
220-
```
200+
"ec2:DescribeAvailabilityZones",
201+
"ec2:DescribeInstances"
202+
],
203+
"Resource": [ "*" ]
204+
}
205+
]
206+
}
207+
```
208+
209+
- Make sure that the security group of the cluster instances has an inbound rule to allow incoming traffic on the Hazelcast default port range `(5701 - 5708)`. It is advised to restrict access to instances in the same security group for this inbound rule.
210+
211+
2. Create a `deployment.toml` file in a preferred directory and add the following configurations.
212+
213+
```toml
214+
[clustering]
215+
membership_scheme = "aws-ecs"
216+
217+
[clustering.properties]
218+
region = "us-east-1"
219+
clusterName = "ECS-IS-CLUSTER"
220+
hostHeader = "ec2"
221+
vpcCidrBlock = "10.0.*.*"
222+
tagValue = "a_tag_value"
223+
```
224+
221225
Under the `clustering.properties` section, set the `region`, `clusterName`, `tagValue` and `vpcCidrBlock` based on the AWS ECS cluster you created in the previous step. The `tagValue` is derived from the auto-generated tag `aws:cloudformation:stack-name` in the AWS cluster. If the `aws:cloudformation:stack-name` tag is not available in the cluster or you prefer to use a custom tag, make sure to specify both the `tagKey` and `tagValue`.
222226

223227
!!! note
@@ -228,43 +232,48 @@ The following configurations need to be done in both the WSO2 Identity Server no
228232
229233
=== "Fargate"
230234

231-
2. Create a working AWS ECS Cluster with Fargate launch type. Note the following when creating a cluster.
232-
- Select the `Fargate` launch type.
233-
- Note the `name` and `VPC CIDR block` of the cluster, as you will require them later for configurations.
234-
- Ensure that the `Task execution role` has the following permissions:
235-
```
236-
{ "Version": "2012-10-17",
237-
"Statement":
235+
1. Create a working AWS ECS Cluster with Fargate launch type. Note the following when creating a cluster.
236+
237+
- Select the `Fargate` launch type.
238+
- Note the `name` and `VPC CIDR block` of the cluster, as you will require them later for configurations.
239+
- Ensure that the `Task execution role` has the following permissions:
240+
241+
```json
242+
{ "Version": "2012-10-17",
243+
"Statement":
244+
[
245+
{
246+
"Effect": "Allow",
247+
"Action":
238248
[
239-
{
240-
"Effect": "Allow",
241-
"Action":
242-
[
243-
"ecs:ListTasks",
244-
"ecs:DescribeTasks",
245-
"ec2:DescribeNetworkInterfaces"
246-
],
247-
"Resource": [ "*" ]
248-
}
249-
]
250-
}
251-
252-
```
253-
- Make sure that the security group of the cluster instances has an inbound rule to allow incoming traffic on the Hazelcast default port range `(5701 - 5708)`. It is advised to restrict access to instances in the same security group for this inbound rule.
254-
255-
1. Create a `deployment.toml` file in a preferred directory and add the following configurations.
256-
```
257-
[clustering]
258-
membership_scheme = "aws-ecs"
259-
260-
[clustering.properties]
261-
region = "us-east-1"
262-
clusterName = "ECS-IS-CLUSTER-FARGATE"
263-
hostHeader = "ecs"
264-
vpcCidrBlock = "10.0.*.*"
265-
tagKey = "a_tag_key"
266-
tagValue = "a_tag_value"
267-
```
249+
"ecs:ListTasks",
250+
"ecs:DescribeTasks",
251+
"ec2:DescribeNetworkInterfaces"
252+
],
253+
"Resource": [ "*" ]
254+
}
255+
]
256+
}
257+
258+
```
259+
260+
- Make sure that the security group of the cluster instances has an inbound rule to allow incoming traffic on the Hazelcast default port range `(5701 - 5708)`. It is advised to restrict access to instances in the same security group for this inbound rule.
261+
262+
2. Create a `deployment.toml` file in a preferred directory and add the following configurations.
263+
264+
```toml
265+
[clustering]
266+
membership_scheme = "aws-ecs"
267+
268+
[clustering.properties]
269+
region = "us-east-1"
270+
clusterName = "ECS-IS-CLUSTER-FARGATE"
271+
hostHeader = "ecs"
272+
vpcCidrBlock = "10.0.*.*"
273+
tagKey = "a_tag_key"
274+
tagValue = "a_tag_value"
275+
```
276+
268277
Under the `clustering.properties` section, set the `region`, `clusterName`, `tagKey`, `tagValue` and `vpcCidrBlock` based on the AWS ECS cluster you created in the previous step. Make sure to specify both the `tagKey` and `tagValue` as Fargate tasks do not have the `aws:cloudformation:stack-name` tag by default.
269278

270279
!!! note
@@ -305,7 +314,7 @@ The following configurations need to be done in both the WSO2 Identity Server no
305314

306315
3. To provide specific permissions for creating an access key and secret key for only this AWS clustering attempt, use the custom policy block given below. See the [AWS documentation](http://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html) for details on how to add the custom IAM policy.
307316
308-
Attach this to the user account that will operate AWS clustering in your WSO2 IS. The access key and secret key can only be used to list EC2 instance details in the AWS account.
317+
4. Attach this to the user account that will operate AWS clustering in your WSO2 IS. The access key and secret key can only be used to list EC2 instance details in the AWS account.
309318
310319
```json
311320
{ "Version": "2012-10-17",
@@ -324,8 +333,8 @@ The following configurations need to be done in both the WSO2 Identity Server no
324333
```
325334

326335
=== "Kubernetes"
327-
328-
When WSO2 IS nodes are deployed in clustered mode on Kubernetes, the Kubernetes Membership Scheme enables the automatic discovery of these servers. The Kubernetes Membership Scheme supports finding the pod IP addresses using the Kubernetes API.
336+
337+
When {{product_name}} nodes are deployed in clustered mode on Kubernetes, the Kubernetes Membership Scheme enables the automatic discovery of these servers. The Kubernetes Membership Scheme supports finding the pod IP addresses using the Kubernetes API.
329338

330339
- Configure the `<IS_HOME>/repository/conf/deployment.toml` file with the following configurations.
331340

@@ -336,32 +345,31 @@ The following configurations need to be done in both the WSO2 Identity Server no
336345
| `KUBERNETES_NAMESPACE` | This is the Kubernetes Namespace in which the pods are deployed. | `wso2-is` |
337346
| `KUBERNETES_SERVICES` | These are the Kubernetes Services that belong in the cluster. | `wso2is-service` |
338347

339-
```toml
340-
[clustering]
341-
membership_scheme = "kubernetes"
342-
local_member_port = "4000"
348+
```toml
349+
[clustering]
350+
membership_scheme = "kubernetes"
351+
local_member_port = "4000"
343352

344-
[clustering.properties]
345-
KUBERNETES_NAMESPACE = "wso2-is"
346-
KUBERNETES_SERVICES = "wso2is-service"
347-
```
353+
[clustering.properties]
354+
KUBERNETES_NAMESPACE = "wso2-is"
355+
KUBERNETES_SERVICES = "wso2is-service"
356+
```
348357

349358
- In order to retrieve the pod IP address information from the Kubernetes api server, the Kubernetes membership scheme uses the pod's service account. Hence, the pods need to be associated with a service account that has permission to read the "endpoints" resource. Make sure the role you bind has the following permissions.
350359

351-
```toml
352-
rules:
353-
- apiGroups: [""]
354-
verbs: ["get", "list"]
355-
resources: ["endpoints"]
356-
```
357-
358-
- Optionally, a Kubernetes token or basic authentication can be used to authenticate with the Kubernetes api server.
359-
The following properties can be set under `[clustering.properties]` accordingly.
360-
- `KUBERNETES_API_SERVER`: This is the Kubernetes API endpoint,e.g., `http://172.17.8.101:8080`. Alternatively, an https endpoint can be set via `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT_HTTPS`.
361-
- `KUBERNETES_SERVICE_HOST`: This is the Kubernetes API hostname or IP address, e.g., `kuberneteshostname`.
362-
- `KUBERNETES_SERVICE_PORT_HTTPS`: This is the Kubernetes API https listening port. This must be an integer value.
363-
- `KUBERNETES_API_SERVER_TOKEN`: This is the Kubernetes Master token for authentication (optional), e.g., `yourkubernetestoken`.
360+
```toml
361+
rules:
362+
- apiGroups: [""]
363+
verbs: ["get", "list"]
364+
resources: ["endpoints"]
365+
```
364366

367+
- Optionally, a Kubernetes token or basic authentication can be used to authenticate with the Kubernetes api server. The following properties can be set under `[clustering.properties]` accordingly.
368+
369+
- `KUBERNETES_API_SERVER`: This is the Kubernetes API endpoint,e.g., `http://172.17.8.101:8080`. Alternatively, an https endpoint can be set via `KUBERNETES_SERVICE_HOST` and `KUBERNETES_SERVICE_PORT_HTTPS`.
370+
- `KUBERNETES_SERVICE_HOST`: This is the Kubernetes API hostname or IP address, e.g., `kuberneteshostname`.
371+
- `KUBERNETES_SERVICE_PORT_HTTPS`: This is the Kubernetes API https listening port. This must be an integer value.
372+
- `KUBERNETES_API_SERVER_TOKEN`: This is the Kubernetes Master token for authentication (optional), e.g., `yourkubernetestoken`.
365373

366374
2. Configure caching.
367375

0 commit comments

Comments
 (0)