What is Environment?

Environment is a runtime execution context for API Proxies in an organization.

One or more API Proxies must be deployed in the environment to be accessed. An API Proxy can be deployed in a single environment or across multiple environments.

An environment provides an isolated, isolated space as a system resource to run API Proxies. Allows the creation of multiple environments on the Apinizer platform.

Environment management is done in two ways:

  • All the necessary Kubernetes definitions for Gateway and Cache Servers are created and managed through the API Manager screen. See.
  • Only the standard data of existing Kubernetes definitions is registered in the API Manager screen. See.

Environment Roles

An environment can be created in different roles as Production, Development/Test, or Sandbox.

The point to note here is that the client must be deployed in at least one environment in order to access API Proxy.


Test Environment

It is used to test API Proxies or Applications that are active in the test environment. Testing can also be done to measure the adequacy of resources in the hardware.

If a product is developed away from the test environment, it may cause problems in progress.

Sandbox Environment

API Proxies and Applications enabled in the sandbox environment are used in the development and testing process. This environment provides the opportunity to perform safe testing without affecting the production process and close to the production process.

It is important because it imitates the situation of the product on the production environment. For example, it makes it easy to add policy to the relevant API Proxy and test it before accessing it on the production environment. This ensures the security of the production environment and helps a developer avoid the risk of accidentally modifying a live application. It is also ensured that the end user can access the application by making sure that it is running.

  • It can be considered what is the difference between test environment and sandbox environment. The product (API Proxy or Application) is activated on the test environment for testing during the development process, and on the sandbox environment to simulate the real user before the product is finished and released to the end user.
  • According to the intended use of API Proxy, it installs to the environment in the relevant role. The same API Proxy can be enabled on different environments for different purposes. Each environment works independently of the others.

Production Environment

It is used for end users to use API Proxies or Applications that are active in the Production environment. This environment is designed to handle the load of clients.

Environment Architecture

The environment is designed for use in environments where many APIs span multiple teams or projects. The Environment concept in Apinizer corresponds exactly to the namespace in kubernetes.

Apinizer'da oluşturduğunuz ve dağıttığınız (deploy) ortam kubernetes'de bir namespace olarak oluşturulmaktadır. Bir ortam içinde namespace, deployment (dağıtım), pod, replica set, service ve access URL (erişim adresi) bileşenleri bulunur.

The environment you create and deploy in Apinizer is created as a namespace in kubernetes. Within an environment, there are namespace, deployment, pod, replica set, service and access URL components.

All environments created with the Apinizer Platform are also contained within the Kubernetes cluster.

Kubernetes clusters can simultaneously manage large volumes of disconnected workloads. Kubernetes uses a concept called namespace to declutter objects within the cluster. Namespaces allow objects to be grouped with each other and filtered and controlled as a unit. Whether used to enforce customized access control policies or to separate entire volumes for a test environment, namespaces are a powerful and flexible framework for managing objects as a group.

Namespaces provide a scope for object names within the set. While names within a namespace must be unique, the same name can be used in different namespaces. This can be useful for some scenarios in practice.

For example, by using Namespaces to categorize application lifecycle environments such as development, test, and product, copies of the same object with the same name can be obtained in every environment. In addition, a desired policy can easily be applied to certain parts of the cluster.

The ability to reuse object names is also a useful feature. Namespaces are also suitable for formatting development, test, and product environments. Objects can migrate to new environments as they are tested and retain their original names.

For detailed information Kubernetes Documentation.

Environment Components

Namespace: The environment concept in Apinizer corresponds to the Namespace concept in Kubernetes environment.

Log Server: It is the connection definition of the Elasticsearch cluster where all API Traffic and requests in the created environment will be logged.

Deployment (Dağıtım): Two deployments are defined as Gateway Engine (Worker Server) and Cache Server.

  • Worker Server: It is the core module of Apinizer Platform, responsible for routing all API requests to BackendAPI and works as Policy Enforcement Point.

  • Cache Server: It is the environment where the Cache values required in Apinizer are kept.

Service: Environment Service is created to access the Apinizer Worker pod in Environment Deployment. The service is the layer that handles requests to all pods. It is located in front of the pods as a location. Service information is defined each time an environment is created. But it is important that all Apinizer Workers in the cluster are managed with a service. In addition, service ports must be unique on the Apinizer Platform. By default, NodePort is used and other service types are not supported by Apinizer.

Access URL: Access Url is the proxy's external access address. It is specified as https://<your-IP-address>. Messages can be sent to Proxies using external access address information.

Entering the Access URL value does not change the working logic of the services. It is only important in terms of facilitating the editing of the access address in the definition file of the service and enabling the clients that will consume the services via Apinizer to come to the address defined in Apinizer.

Environment Access Address

An API can access the Proxy via the access address of the environment in which it is deployed.

Let the access address of an API Proxy be: http://demo.apinizer.com/apigateway/myproxy

The access address to be defined for the environment is usually the DNS address defined in a load balancer such as WAF or Nginx. Environments defined in Apinizer correspond to a namespace in kubernetes. An automatic NodePort type Kubernetes service is created by Apinizer to access Apinizer Workers running in Namespace. A service is created with the value entered in the Engine Service Port while creating the environment.

An example service information for accessing Apinizer Worker;

  • If the Engine Service Port value is 30080 (it is the default value and should be different for each environment.), it is necessary to specify the DNS definition in WAF or your Nginx server as follows.
     http://kubernetes-worker-node-IP:30080/