We will introduce the configuration of Nocalhost, how to modify it and its features, etc. If you don't have a concept of the configuration of Nocalhost, or want to know more about its structure and features, please read this section.
Development configuration is set around
DevMode, such as which image should be used to enter
DevMode, whether the persistence is needed in the development container, which files should be synchronized to the development container, how to debug and run the service in the container by one-click, etc. The
DevMode in Nocalhost will be more easier to use with correct and appropriate development configuration.
Overall, development configuration is to better define the behavior of
Development Configuration and Deployment Configuration
The configuration of Nocalhost can be divided into two parts: development configuration and deployment configuration.
Deployment configuration defines how K8s applications deployed, including dependency control, variable injection, etc.
Development configuration is set around
DevMode, such as which image should be used in
DevMode, whether the persistence is needed in the development container, which files should be synchronized to the development container, how to debug and run the service in the container by one-click, etc.
Normally, only Development configuration needs to be concerned. In the configuration document, the configuration we mention refers to the development configuration unless noted otherwise.
If you have never configured Nocalhost for any workload, right-click it and select
Dev Config, then you will see the empty configurations as below, which are all commonly used in the
DevMode of Nocalhost.
Configuration is not a must
You can enter
DevMode without any configuration.
We can make any changes and use
S on the IDE plugin side to save them.
serviceType at the top level of the configuration indicate that this configuration belongs to the
coredns . The content of the configuration is in
containers , which is an array and can set different configurations for multiple containers in one workload.
First, you have to declare the name of each container in
containers..name to distinguish each container.#
For example, if there are two containers in the workload,
ContainerB (note that this is just an example, and the container should be named according to your real workload) , then you need to declare the names as follows:
Surely, if you only need to develop
ContainerB , you can configure it only. As follows:
This part indeed requires a long and detailed explanation, but we first give a simple example here to offer a quick start for Nocalhost configuration.
Need an application to operate?
If there is no workload to operate, you can use the following command to install a demo application:
Right-click a workload that has never been configured, such as details-v1. Click
DevConfig, then you will see an empty template. Let's make some changes, such as adding an additional env to the development container (the development container will inherit the environment variables from the original container):
S to save the changes, and then enter the
DevMode. Since it is just a demonstration of the configuration process, you can select any local directory here and its content will be synchronized to the development container, and then you can select any development image.
env | grep nocalhost in the terminal after initiating the
DevMode. As you can see, the environment variables have been injected correctly.
To learn more about configuration items and corresponding functions, see What configurations does Nocalhost offer?
In addition, the design of the Nocalhost configuration also brings some features. Knowing these features may help you better use Nocalhost.
The development configuration of nocalhost does not take effect immediately. It needs to be saved and then re-enter the
DevMode to make it work.
Nocalhost will create a
secret in each namespace as a "mini database", prefixed with
dev.nocalhost.application.. The configuration will be saved in this
Data will be remained in this
secret until it is destroyed.
If it is a HELM application, for example, its
secret will be named
dev.nocalhost.application.bookinfo. Moreover, the data stored in this
secret will be destroyed after uninstalling
From the storage design, you can find that the configuration of Nocalhost is shared. Specifically, in the same
namespace of the same cluster, the configuration of one workload is visible on any device and can be modified (with the modification permission of the
secret of RBAC ). The configuration all devices get is from the same duplicate.