seg_yinzy
/
che-server
mirror of https://github.com/eclipse-che/che-server.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
che-server/dockerfiles/init/manifests/che.env

465 lines
24 KiB
Bash
Raw Blame History

########################################################################################
##### #####
##### CHE SYSTEM #####
##### #####
#
# Parameters that affect the initial system operation.
#
# IP address, hostname, or DNS
# The IP address or DNS name of where the Che endpoint will service your users.
# If you are running this on a local system, we auto-detect this value as the IP
# address of your Docker daemon. On many systems, especially those from cloud hosters
# like DigitalOcean, you must explicitly set this to the external IP address or
# DNS entry provided by the provider. This value can be overridden on the command
# line with '-e CHE_HOST=<value>'.
#CHE_HOST=localhost
# Port
# The port on the host Che will bind itself to. This value can be overridden on the
# command line with '-e CHE_PORT=<value>'.
#CHE_PORT=8080
# Proxies
# Che's internal services such as Java & curl need system properties applied
# so they can reach the Internet. Che uses the Internet to reach DockerHub
# and to route workspace activity. Che is configured to inherit proxy
# parameters from your Docker daemon settings. Those settings are applied
# to these variables automatically during initialization, but you can override
# them here.
#
# Please be mindful of proxy URL formatting. Proxies are unforgiving if the URL is
# not typed properly, including the protocol and a trailing slash '/'.
#CHE_HTTP_PROXY=http://myproxy.com:8001/
#CHE_HTTPS_PROXY=http://myproxy.com:8001/
#CHE_NO_PROXY=<ip-or-domains-that-do-not-require-proxy-access>
# Proxies for Workspaces
# The proxy values that will be set as environment variables within each user's.
# workspace. Set these to allow users Internet access if they are behind a proxy.
#CHE_WORKSPACE_HTTP__PROXY=http://myproxy.com:8001/
#CHE_WORKSPACE_HTTPS__PROXY=http://myproxy.com:8001/
#CHE_WORKSPACE_NO__PROXY=<ip-or-domains-that-do-not-require-proxy-access>
# DNS resolving servers
# Comma separate list of IP address that point to DNS resolving servers. In
# some secure environments or those behind a proxy, custom DNS resolution
# is required to resolve DNS names. You can set internal DNS servers or external
# ones to this configuration. This applies DNS resolution to the Che server and
# to the runtimes of the workspaces created from this Che server. This value
# defaults to inheriting DNS resolver list from host running Che.
#CHE_DNS_RESOLVERS=<ip-of-dns-resolving-servers>
# JPDA
# If using Che in development mode, activate this property to enable JPDA
# mode within Che's internal Tomcat
#CHE_DEBUG_SUSPEND=false
#CHE_DEBUG_PORT=8000
# XMX
# Che's core server runs as a Tomcat application on top of a JVM. This sets the
# JVM XMX settings that are loaded by the JVM when the Che container boots.
# It should be rare that you would need to change this.
#CHE_SERVER_XMX=2048
########################################################################################
##### #####
##### WORKSPACES #####
##### #####
#
# User workspaces have their own runtimes. Those runtimes are composed of 1..n containers.
# We call each container a 'machine' as it is a dedicated runtime. One of the machines for
# a workspace must be designated as the 'development' machine, which installs Che agents to
# provide additional services to the user. These parameters configure how Che manages user
# machines and the agents that are deployed within them.
#
# Since workspaces have their own runtimes, they have separate proxies that do not inherit
# from system proxies that you have configured for your Docker daemon.
#
# Extra Hosts for Workspaces
# Comma separated list of <HOST>:<IP> entries that will be added to the user's
# /etc/hosts file within their workspace runtimes. Configure this to give user
# access to systems within your network. This is set when DNS resolvers do not
# parse hostname entries properly.
#CHE_WORKSPACE_HOSTS=<HOST_1>:<IP_1>,<HOST_2>:<IP_2>
# Memory
# The recommended RAM size for new workspaces when created from the dashboard.
#CHE_WORKSPACE_DEFAULT__MEMORY__MB=1024
# Memory Swap
# Adjust machine swap memory by multiplication current machnine memory on provided
# value. Default is 0 which means disabled swap, if set multiplier value equal to 0.5
# machine swap will be configured with size that equal to half of current machine memory.
# It should be rare that you would configure this. See Docker memory swap online
# for background.
#CHE_DOCKER_SWAP=0
# Host Volume Mounts
# Semicolon separated list of volume mounts. Che will volume mount these host folders
# into each workspace. This is a way to allow you to provide access to NAS shared
# across many workspaces.
#CHE_WORKSPACE_VOLUME=/path/on/host:/path/in/workspace:ro,Z;/path/to/host2:/path/in/workspace2:ro,Z;
# Privileged Mode
# Set to `true` if you would like user workspaces to be started with Docker's
# privileged mode. Please be careful when setting this property. This allows
# user workspaces to gain access to the underly host with root privileges.
# However, privileged mode is needed if users want to launch their own Docker
# containers from within their Docker-powered workspace.
#CHE_DOCKER_PRIVILEGED=false
# Agent Start Timeout
# The length of time that a workspace will be allowed to boot before the system terminates the
# boot process. If the Che container cannot establish two way communications with the
# agents within the workspace when it boots, then the workspace will not be started.
#CHE_WORKSPACE_AGENT_DEV_MAX__START__TIME__MS=300000
# Workspace Agent Java Options
# Java command line options to be added to JVM's that run agents within workspaces.
#CHE_WORKSPACE_JAVA_OPTIONS=-Xms256m -Xmx2048m -Djava.security.egd=file:/dev/./urandom
# Workspace Agent Maven Options
# Maven command line options added to JVM's that run agents within workspaces.
# Defaults to the same value of CHE_WORKSPACE_JAVA_OPTIONS.
#CHE_WORKSPACE_MAVEN_OPTIONS=NULL
########################################################################################
##### #####
##### NETWORKING #####
##### #####
#
# Affects how the Che server connects to the Docker Daemon, how the Che server and
# workspaces establish connections to one another, and also how remote browser clients
# should discover and connect to workspaces.
#
# Che goes through a progression algorithm to establish the protocol, IP address and
# port to establish communications with it is booting or starting a workspace.
#
# Browser --> Che Server
# 1. Default is 'http://localhost:${SERVER_PORT}/wsmaster/api'.
# 2. Else use the value of CHE_API
#
# Che Server --> Docker Daemon Progression:
# 1. Use the value of CHE_DOCKER_DAEMON__URL
# 2. Else, use the value of DOCKER_HOST system variable
# 3. Else, use Unix socket over unix:///var/run/docker.sock
#
# Che Server --> Workspace Connection:
# - If CHE_DOCKER_SERVER__EVALUATION__STRATEGY is 'default':
# 1. Use the value of CHE_DOCKER_IP
# 2. Else, if server connects over Unix socket, then use localhost
# 3. Else, use DOCKER_HOST
# - If CHE_DOCKER_SERVER__EVALUATION__STRATEGY is 'docker-local':
# 1. Use the address of the workspace container within the docker network
# and exposed ports
# 2. If address is missing, if server connects over Unix socket, then use
# localhost and exposed ports
# 3. Else, use DOCKER_HOST and published ports
#
# Browser --> Workspace Connection:
# - If CHE_DOCKER_SERVER__EVALUATION__STRATEGY is 'default':
# 1. If set use the value of CHE_DOCKER_IP_EXTERNAL
# 2. Else if set use the value of CHE_DOCKER_IP
# 3. Else, if server connects over Unix socket, then use localhost
# 4. Else, use DOCKER_HOST
# - If CHE_DOCKER_SERVER__EVALUATION__STRATEGY is 'docker-local':
# 1. If set use the value of CHE_DOCKER_IP_EXTERNAL
# 2. Else use the address of the workspace container within the docker network,
# if it is set
# 3. If address is missing, if server connects over Unix socket, then use
# localhost
# 4. Else, use DOCKER_HOST
#
# Workspace Agent --> Che Server
# 1. Default is 'http://che-host:${SERVER_PORT}/wsmaster/api', where 'che-host'
# is IP of server.
# 2. Else, use value of CHE_WORKSPACE_CHE__SERVER__ENDPOINT
# 3. Else, if 'docker0' interface is unreachable, then 'che-host' replaced with
# 172.17.42.1 or 192.168.99.1
# 4. Else, print connection exception
# Che Server API Endpoint
# The location of the API end point where dashboard and IDE clients will look for
# interacting with the Che server, which we also call the workspace master.
#CHE_API=http://${CHE_HOST}:${CHE_PORT}/wsmaster/api
#CHE_WEBSOCKET_ENDPOINT_BASE=ws://${CHE_HOST}:${CHE_PORT}
# Docker Daemon URL
# How the Che server will discover the location of the Docker daemon. If this is
# not set, then Che will use DOCKER_HOST or the default unix:///var/run/docker.sock.
# It would be rare to need to set this as most clients set DOCKER_HOST or volume
# mount a Docker socket when starting the Che CLI.
#CHE_DOCKER_DAEMON__URL=NULL
# Docker Host
# How Che will connect to the Docker host if CHE_DOCKER_DAEMON__URL is not set. This
# value can be provided on the command line as well. If this value is not set, then
# Che will use the volume mount of unix:///var/run/docker.sock.
#DOCKER_HOST=tcp://localhost:2375
# Workspace Address Resolution Strategy
# The strategy to determine how workspace servers users launch will be exposed.
# If the Che server and your workspaces are on different networks that flow through a
# firewall, those firewalls can prevent communications between Che and workspaces.
# The default strategy exposes workspaces with the IP of Docker and ephemeral ports.
# A Docker local strategy uses internal Docker network IP addresses and exposed ports.
#
# Options:
# - 'default': internal address is DOCKER_HOST with ephemeral ports
# - 'docker-local': internal address is Docker network container address with
# exposed ports (not ephemeral)
# on the same Docker network.
#CHE_DOCKER_SERVER__EVALUATION__STRATEGY=docker-local
# Docker IP Address
# The IP address of the Docker daemon that is running on your host. The Che server
# uses this IP address to establish a connection to your workspaces when they
# first boot. This is different from how the Che server first establishes a
# connection to the Docker daemon. After a Che server has instructed a Docker
# Daemon to create a workspace, the Che server then discovers the location of the
# workspace using the value of this IP address. We use auto-discovery to determine
# this IP address. You can provide this value to override the default discovery
# which searches Unix sockets and DOCKER_HOST.
#CHE_DOCKER_IP=172.17.0.1
# External Docker IP Address
# The external IP address used by browsers to connect to workspace containers that
# are running on a Docker network. After Che has created a workspace runtime, those
# Docker containers need to be reachable by remote browsers. Browsers will default
# to using CHE_DOCKER_IP, then unix sockets, or DOCKER_HOST if this is not set.
# This will generally work if the browser and the workspace are on the same network.
# However, if the browser and the workspaces are on different networks, then you
# may need to set this value to the external IP address of your host or Docker to
# make workspaces reachable.
#CHE_DOCKER_IP_EXTERNAL=NULL
# Usage of single-port routing.
# By enabling single-port, all browser traffic to Che or any workspace will be routed
# through the value that you have set to CHE_PORT`, or 8080 if not set. Setting this
# property will transform the launch sequence of Che to launch a Traefik reverse proxy.
# The reverse proxy will act as the traffic endpoint for all browser communications.
# When a new workspace is started or stopped, Che will update Traefik's configuration
# with rules for how browser traffic should be routed to Che or a workspace.
#
# With single-port, each service running in a workspace and exposing ports has its own hostname.
# Example : workspace agent will have a hostname like : ws-agent.workspace-id....domain.name
# By default the domain name will use nip.io which allow to provide wildcard DNS without any
# user configuration. The strategy used for the hosts is using the template provided by the
# CHE_DOCKER_SERVER__EVALUATION__STRATEGY_CUSTOM_TEMPLATE property with default value
# <serverName>.<machineName>.<workspaceId>.<wildcardNipDomain>:<chePort>
# If you've your own domain and then DNS server, you may want to add wildcard DNS entry
# matching a pattern. For example updating the property to the value
# <serverName>.<machineName>.<workspaceId>.che.foobar.com:<chePort>
# will require a wildcard *.che.foobar.com entry in DNS server resolving to the IP of the che server.
# More details on the values provided by the template can be found on documentation.
CHE_SINGLE_PORT=false
########################################################################################
##### #####
##### DOCKER #####
##### #####
#
# Docker Registry for Workspace Snapshots
# Docker is the default machine implementation within Che. Workspaces are powered
# by machines that are constructed when the workspace is started. The images used to
# generate containers for the machines can come from DockerHub or a private
# Docker registry. When a workspace is "stopped", if it is saved as a snapshot, then
# the workspace's runtime is saved as a Docker image to disk. You can optionally
# have this image saved in a Docker registry like Artifactory or Docker Enterprise
# registry. The default location for workspace snapshots is on disk. You can
# configure this property with a URL to your registry to alter the location.
#CHE_DOCKER_REGISTRY=${CHE_REGISTRY_HOST}:5000
#
# If false, snaps are saved to disk. If true, snaps are saved in a registry.
# The namespace is how the snapshots will be organized in the registry.
#CHE_DOCKER_REGISTRY__FOR__SNAPSHOTS=false
#CHE_DOCKER_NAMESPACE=NULL
# By default, when users stop their workspaces, they are not snapped. You can set this
# to automatically create snaps when they stop either due to user stopping the
# workspace or idle timeout.
#CHE_WORKSPACE_AUTO__SNAPSHOT=false
#CHE_WORKSPACE_AUTO__RESTORE=false
# By default, if a user accesses a workspace from its unique URL (instead of the
# dashboard interface), then the workspace is automatically started by Che.
# You can set this property to false to disable this behavior.
#CHE_WORKSPACE_AUTO__START=true
# Private Docker Images
# If pushing snap images to a registry requires authenticated access to the
# registry. Or, if your stacks reference private images which require authenticated
# access to a registry in order to pull, then you can configure 1..n registries
# with authentication access. We will perform a `docker login` with this
# credentials before performing a snap or a pull.
#CHE_DOCKER_REGISTRY_AUTH_<insert-name>_URL=https://index.docker.io/v1/
#CHE_DOCKER_REGISTRY_AUTH_<insert-name>_USERNAME=<username>
#CHE_DOCKER_REGISTRY_AUTH_<insert-name>_PASSWORD=<password>
#CHE_DOCKER_REGISTRY_AWS_REGISTRY1_ID=id1
#CHE_DOCKER_REGISTRY_AWS_REGISTRY1_REGION=region1
#CHE_DOCKER_REGISTRY_AWS_REGISTRY1_ACCESS__KEY__ID=key_id1
#CHE_DOCKER_REGISTRY_AWS_REGISTRY1_SECRET__ACCESS__KEY=secret1
# Force Image Update
# If true, then Che always pulls an image from a registry even if it is cached
# If false, Docker only pulls the image if it does not exist locally. This can
# create situations where images are not current, but a forced pull is slower.
#CHE_DOCKER_ALWAYS__PULL__IMAGE=true
# Control User Processes
# Limits the number of processes that can be forked inside a cgroup. Set -1 for
# unlimited. Requires Docker running on a 4.3 Linux kernel.
#CHE_DOCKER_PIDS__LIMIT=-1
# CPU Core Limits
# Limit the CPU cores used for running Che workspaces as containers.
# Example:
# CHE_DOCKER_CPUSET__CPUS=0-3
# CHE_DOCKER_CPUSET__CPUS=0,2
# See more at https://docs.docker.com/engine/reference/run/#/cpuset-constraint
#CHE_DOCKER_CPUSET__CPUS=NULL
# CPU Consumption Limit
# Limit the CPU utilitization given to containers powering workspaces started
# by Che. 'period' sets the amount of units for each CPU core. 'quota' sets the
# sets amount of units available per whole CPU.
# Max value of quota could be period * number of CPU cores in a system.
# Example:
# These values allows usage of 100% of 2 cores on 2+ cores system.
# Period declares that 100% is equal to 5000 units
# and container is allowed to use 2x more than 1 core.
# Although max consumption is explained in cores performance workload will be
# split between several cores.
# CHE_DOCKER_CPU__PERIOD=5000
# CHE_DOCKER_CPU__QUOTA=10000
# In this example limit is set to half of a CPU core.
# CHE_DOCKER_CPU__PERIOD=10000
# CHE_DOCKER_CPU__QUOTA=5000
# See more at https://docs.docker.com/engine/reference/run/#/cpu-period-constraint
# https://docs.docker.com/engine/reference/run/#/cpu-quota-constraint
#CHE_DOCKER_CPU__PERIOD=0
#CHE_DOCKER_CPU__QUOTA=0
# CGroup Parent
# CGroups allow admins to to configure limits on nodes in a system in a specific
# way. The value can start with a slash which means it will be absolute or
# without a slash for relative value. Docker will create this cgroup if it is missing.
# Admin can configure limits on this cgroup on all nodes in a system specific way.
# Example:
# On Ubuntu 16.04 use CHE_DOCKER_PARENT__CGROUP=/my_group. Then let container
# create cgoup by running Che. Then edit
# /sys/fs/cgroup/<resource folder>/my_group/<resource file>
# For example to limit CPU cores to 0-1 put value "0-1" into file
# /sys/fs/cgroup/cpuset/my_group/cpuset.cpus
# See more at https://docs.docker.com/engine/reference/run/#/specifying-custom-cgroups
#CHE_DOCKER_PARENT__CGROUP=NULL
# SELinux Options
# By default, your source code is mounted into a workspace into /projects folder.
# On SELinux and other OS, you may need to add additional mounting attributes.
#CHE_DOCKER_VOLUMES__PROJECTS__OPTIONS=Z
#CHE_DOCKER_VOLUMES__AGENT__OPTIONS=ro,Z
# Docker Network
# Provides a Docker network for the Che server and workspaces to use together.
# Workspace containers created by Che will be added to this Docker network.
# Communications between the Che server and container occur over this network.
#CHE_DOCKER_NETWORK=NULL
# Docker Cleanup
# Unused containers and networks from Che and workspaces need to be cleaned up
# periodically.
#CHE_DOCKER_CLEANUP__PERIOD__MIN=60
########################################################################################
##### #####
##### OAUTH #####
##### #####
#
# You can configure a 3rd party provider's oAuth, which will be used for your users when
# they initiate Git actions from within Che.
#
# GitHub
#CHE_OAUTH_GITHUB_CLIENTID=your_github_client_ide
#CHE_OAUTH_GITHUB_CLIENTSECRET=your_google_secret
#CHE_OAUTH_GITHUB_AUTHURI=https://github.com/login/oauth/authorize
#CHE_OAUTH_GITHUB_TOKENURI=https://github.com/login/oauth/access_token
#CHE_OAUTH_GITHUB_REDIRECTURIS=http://localhost:${CHE_PORT}/wsmaster/api/oauth/callback
########################################################################################
##### #####
##### JMX #####
##### #####
#
# JMX provides a management interface point to within the Che container. JMX is not
# use by other containers such as haproxy or nginx. While Che is running, grab the
# IP address of the Che container and you can connect to its embedded JMX server.
# JMX is disabled by default, uncomment CHE_JMX_ENABLED=true to enable it.
#
#CHE_JMX_ENABLED=true
#CHE_JMX_USERNAME=admin
#CHE_JMX_PASSWORD=Che
########################################################################################
##### #####
##### CUSTOM #####
##### #####
# Custom che.properties Property
# Che's server loads name=value properties in a .properties file. Those values can
# be seen by custom extensions that are packaged within a Che server. There are
# also Che properties that are rarely configured that are shown in documentation
# that can be added with a custom format here. You can add as many as you would like.
#
# Add a new property in the format of CHE_<PROPERTY_NAME>=value. If in your
# <PROPERTY_NAME> you have a single underscore '_', that will be replaced with a
# dot '.'. A double underscore '__' will be replaced with a single underscore '_'.
#
# For example, CHE_WORKSPACE_AUTO__SNAPSHOT=false will be converted into the Che
# property 'che.workspace.auto_snapshot=false'.
#CHE_WORKSPACE_AUTO__SNAPSHOT=false
# A complete list of internal properties used by Che are available in the default
# properties file that is embedded in the server's runtime. You can view it in our
# GitHub repository: https://github.com/eclipse/che/blob/master/assembly/assembly-wsmaster-war/src/main/webapp/WEB-INF/classes/codenvy/che.properties
########################################################################################
##### #####
##### STACKS #####
##### #####
#
# Defines whether stacks loaded once or each time server starts.
# If value is 'false' stacks will be loaded once after database is initialized,
# otherwise stacks will be loaded each time server starts.
# Stacks loading overrides existing predefined stacks with new data
# defined in stacks.json.
# - 'default' : false
# Note that this property is needed for backward compatibility and will be removed soon.
#CHE_PREDEFINED_STACKS_RELOAD__ON__START=false
########################################################################################
##### #####
##### Openshift Infrastructure #####
##### #####
#
#CHE_INFRA_OPENSHIFT_MASTER__URL=
#CHE_INFRA_OPENSHIFT_USERNAME=developer
#CHE_INFRA_OPENSHIFT_PASSWORD=developer
#CHE_INFRA_OPENSHIFT_TRUST__CERTS=false
#CHE_INFRA_OPENSHIFT_MACHINE__START__TIMEOUT__MIN=5
#CHE_INFRA_OPENSHIFT_CHE__SERVER__ENDPOINT=http://che-host:${CHE_PORT}/wsmaster/api
#CHE_INFRA_OPENSHIFT_CHE__SERVER__WEBSOCKET__ENDPOINT__BASE=ws://che-host:${CHE_PORT}/wsmaster
#CHE_INFRA_OPENSHIFT_BOOTSTRAPPER_BINARY__URL=http://che-host:${CHE_PORT}/agent-binaries/linux_amd64/bootstrapper/bootstrapper
Reference in New Issue View Git Blame Copy Permalink