Migrate usages of HOSTNAME_EXTERNAL and LOCALSTACK_HOSTNAME

content/en/getting-started/faq.md

@@ -117,23 +117,10 @@ sudo sysctl -w net.ipv4.ip_forward=1
 
 ### Why can't my other Docker containers reach LocalStack?
 
-Using LocalStack inside a Docker network with multiple other containers can lead to connectivity issues from/to those containers. For example, a container which attempts to deploy a stack and interact with the services directly, from within the same Docker network.
+Using LocalStack inside a Docker network with multiple other containers can lead to connectivity issues from/to those containers.
+For example, a container which attempts to deploy a stack and interact with the services directly, from within the same Docker network.
 
-To resolve this, set `HOSTNAME_EXTERNAL` for correct response values for endpoints. Use network aliases to ensure resolution of `localhost.localstack.cloud` to the correct container:
-
-```yaml
-...
-    networks:
-      default:
-        aliases:
-          - localhost.localstack.cloud
-  sdkstack:
-    image: ubuntu
-    command: ["bash", "-c", "apt update && apt install -y curl && sleep 5 && curl -v http://localhost.localstack.cloud:4566/_localstack/health"]
-...
-```
-
-Note the missing `network: bridge` here! The default bridge network does not support DNS name resolution.
+Refer to our [network troubleshooting guide]({{< ref "references/network-troubleshooting" >}}) covering several scenarios.
 
 ### How to resolve the pull rate limit issue for LocalStack's Docker image?
 

content/en/user-guide/aws/elastic-kubernetes-service/index.md

@@ -100,12 +100,13 @@ You can now use ECR (Elastic Container Registry) images within your EKS environm
 
 #### Initial configuration
 
-To modify the return value of resource URIs for most services, including ECR, you can utilize the `HOSTNAME_EXTERNAL` variable in the [configuration]({{< ref "configuration" >}}). By default, ECR returns a `repositoryUri` starting with `localhost`, such as: `localhost:<port>/<repository-name>`. However, if you set the `HOSTNAME_EXTERNAL` to `localhost.localstack.cloud`, the ECR will provide a `repositoryUri` like `localhost.localstack.cloud:<port>/<repository_name>`.
+To modify the return value of resource URIs for most services, including ECR, you can utilize the `LOCALSTACK_HOST` variable in the [configuration]({{< ref "configuration" >}}).
+By default, ECR returns a `repositoryUri` starting with `localhost.localstack.cloud`, such as: `localhost.localstack.cloud:<port>/<repository-name>`.
 
 {{< alert title="Notes" >}}
 In this section, we assume that `localhost.localstack.cloud` resolves in your environment, and LocalStack is connected to a non-default bridge network. For more information, refer to the article about [DNS rebind protection]({{< ref "dns-server#dns-rebind-protection" >}}).
 
-If the domain `localhost.localstack.cloud` does not resolve on your host, you can still proceed without setting `HOSTNAME_EXTERNAL`. However it is suggested to use `localhost.localstack.cloud` as the registry in your pod configuration. 
+If the domain `localhost.localstack.cloud` does not resolve on your host, you can still proceed by setting `LOCALSTACK_HOST=localhost` (not recommended). 
 
 LocalStack will take care of the DNS resolution of `localhost.localstack.cloud` within ECR itself, allowing you to use the `localhost:<port>/<repository_name>` URI for tagging and pushing the image on your host.
 {{< / alert >}}

content/en/user-guide/ci/gitlab-ci/index.md

@@ -20,8 +20,8 @@ We recommend taking the following steps:
 - Add GitLab CI variables using the keyword variables to include `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, and `AWS_DEFAULT_REGION`.
 - Create a service using the keyword `services` and reference `docker:20.10.16-dind` to pull the latest Docker image and assign an alias for the container (`docker` in our case). Use the `command` option to disable TLS with `--tls=false`.
 - Install LocalStack and/or AWS-related dependencies to define the commands that should be run before all builds.
-- In the `before_script` section, add commands to set up the `LOCALSTACK_HOSTNAME` and `HOSTNAME_EXTERNAL` environment variables and append `localhost.localstack.cloud` to `/etc/hosts` using the IP address of the `docker` service.
-- In the script section, pull the `localstack/localstack` Docker image, start LocalStack in detached mode, and run your LocalStack-related tests.
+- In the `script` section, append `localhost.localstack.cloud` to `/etc/hosts` using the IP address of the `docker` service.
+- In the `script` section, pull the `localstack/localstack` Docker image, start LocalStack in detached mode, and run your LocalStack-related tests.
 
 The following example Gitlab CI job config (`.gitlab-ci.yml`) executes these steps, creates a new S3 bucket, copies some content to the bucket, and checks the content of the bucket:
 
@@ -39,8 +39,6 @@ test:
     AWS_DEFAULT_REGION: us-east-1
     DOCKER_HOST: tcp://docker:2375
     DOCKER_TLS_CERTDIR: ""
-    LOCALSTACK_HOSTNAME: localhost.localstack.cloud
-    HOSTNAME_EXTERNAL: localhost.localstack.cloud
 
   services:
     - name: docker:20.10.16-dind
@@ -62,6 +60,13 @@ test:
     - aws --endpoint http://localhost.localstack.cloud:4566 s3 ls s3://test/
 ```
 
+<details>
+<summary>For LocalStack versions before 3.0.0</summary>
+Under test>variables, add:<br>
+LOCALSTACK_HOSTNAME: localhost.localstack.cloud<br>
+HOSTNAME_EXTERNAL: localhost.localstack.cloud.
+</details>
+
 {{< alert title="Note">}}
 While working with a Docker-in-Docker (`dind`) setup, the Docker runner requires `privileged` mode. You must always use `privileged = true` in your GitLab CI's `config.toml` file while setting up LocalStack in GitLab CI runners. For more information, see [GitLab CI Docker-in-Docker](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-executor) documentation.
 {{< /alert >}}

content/en/user-guide/integrations/serverless-framework/index.md

@@ -106,23 +106,22 @@ Usually, all of LocalStack's services are available via a specific port on local
 
 Since the Lambda functions execute within the LocalStack Docker container, Lambda functions cannot access other services via the usual localhost endpoint. 
 
-Instead, LocalStack provides a special environment variable `LOCALSTACK_HOSTNAME` which contains the internal endpoint of the LocalStack services from within its runtime environment.
+Instead, LocalStack provides a special environment variable `AWS_ENDPOINT_URL` which contains the internal endpoint of the LocalStack services from within its runtime environment.
 
-Hence, you need to configure the Lambda functions to use the `LOCALSTACK_HOSTNAME` endpoint when accessing other AWS services in LocalStack.
+Hence, you need to configure the Lambda functions to use the `AWS_ENDPOINT_URL` endpoint when accessing other AWS services in LocalStack.
 
-In Python, this may look something like. The code detects if it is running in LocalStack by checking if the `LOCALSTACK_HOSTNAME` variable exists and then configures the endpoint URL accordingly.
+In Python, this may look something like. The code detects if it is running in LocalStack by checking if the `AWS_ENDPOINT_URL` variable exists and then configures the endpoint URL accordingly.
 
 ```python
 ...
-if 'LOCALSTACK_HOSTNAME' in os.environ:
-    dynamodb_endpoint = 'http://%s:4566' % os.environ['LOCALSTACK_HOSTNAME']
-    dynamodb = boto3.resource('dynamodb', endpoint_url=dynamodb_endpoint)
+if 'AWS_ENDPOINT_URL' in os.environ:
+    dynamodb = boto3.resource('dynamodb', endpoint_url=os.environ['AWS_ENDPOINT_URL'])
 else:
     dynamodb = boto3.resource('dynamodb')
 ...
 ```
 
-> Ideally, we want to make LocalStack's Lambda execution environment "LocalStack-agnostic", so that you are not required to adjust endpoints in your function code anymore. You want to help us with that? [Drop us a line in Slack](https://localstack-community.slack.com)!.
+In LocalStack Pro, no code changes are required using our [Transparent Endpoint Injection]({{< ref "user-guide/tools/transparent-endpoint-injection" >}}).
 
 ## Deploying to LocalStack
 You can now deploy your Serverless service to LocalStack.