When you enter the image name, you can append extra information (AFTER the version.)
this information MUST start with --, even if you have not stated a version, and is divided by a --
The things you can state are:
--peer--[value] port controls--user--[value]--gptcp1--[value]--gpudp1--[value]--gptcp2--[value]--gpudp2--[value]--env1--[KEY]-[VALUE]--env2--[KEY]-[VALUE]--env3--[KEY]-[VALUE]--env4--[KEY]-[VALUE] you can add as many --envX as you wish --sec1--[name] this adds additional secret paths, you can add many --secX (see separate FAQ section for this)--vol1--[name] this adds additional volume/paths to the image--domain--[domainname.com] when using your OWN doman (see below)--subdomian--[name] to use a subdomain of this evernode--contract--true can be used with "true", to force hotpocket run /contract", or add in your own command to run as entrypoint (this overrides the images default)--ssl--false this is effect the type of incoming connection is listened to, so will be a http:// externally--proxyssl--false will make the connection from the internal proxy to the instance be http://
--dns--false will force the DNS system to ONLY query other evernodes for SSL files and not call LetsEncrypt
--debug--true disables the authorization layer on your instance, allowing the execute command form in instance control, a useful test combined with the Auth logs (see docker secrets FAQ).
Notes: You can add these in any order, and as many as you want to change.If you don't state these, then the default will be used.
there is a128 Character limit
when docker pulls the image, it uses the stated image (and the version) ONLY, and ignores anything after the -- which allow you to use STOCK images.
Use alpha numeric characters (a-z A-Z and 0-9) no spaces, with ONLY the additional characters of, fullstop ., underscores _, and dashes -
but there is a handy character substitutions available;
... to a dollar-sign$.. to a dash -___ to a slash /__ to a "space"(these substitutions are applied in this order)
Basic example using a stock image.
jgraph/drawio:latest--gptcp1--8443
This maps the "general TCP port 1" to the internal port of 8443.
and as we used the general port 1 (gptcp1), which gets a routed to the default domain that is assigned (this can be used WITHOUT :port) this can be accessed externally on just the domain.
Advanced example (Minecraft server):
itzg/docker--minecraft-server:latest--user--25565--gptcp1--19133--env1--EULA-TRUE
so this links 2 of the given external ports to the defaulted internal ports that this image uses (the default minecraft port)
and also sets environment EULA=TRUE which for this image auto accepts the EULA terms
Advanced example using stock datagram image:
svetekllc/datagram:1.1.4--contract--run__....__..key__somenumbersforpublickey--gpudp1--51820
so this uses a contract command with character substitutions to start a run command on start up run -- key somenumbersforpublickey
along with opening internal port 51820 to the assigned external general UDP port 1
So depending on the docker image that you use, will depend what port you should assign to the internal "gptcp1" for this link/port-forwarder to work
For example: If using a image that has a web server inside, like draw.io image, you would specify --gptcp1--8443 as port 8443 is the port that is used internally for that web server,
then the given external port for gptcp1 in the instance gets assigned to this internal TCP port, this gptcp1 port is the only port that is link from domain, to this assigned internal port.
so here it is effectively equivalent to the stock docker command -p 443:8443
you can assign a subdomain to your instance, with --subdomain--customname, this will then create and route customname.thisevernodesdomain.here as a working url to your instance. by routing it to the assigned (gptcp1) general TCP port 1 (what ever the assigned external tcp port 1 is given for your instance is).
or you can specify --domain--yourdomain.com to use your OWN domain, which then the specified domain gets routed to the (gptcp1) general TCP port 1 (what ever the assigned external tcp port 1 is given for your instance is).
Notes: We use the TXT record to protect your domain, so ONLY the instance that YOU create can be tied to YOUR domain, and the NS record on the subdomain _acme-challenge. so we can use DNS-01 method of getting SSL files for your domain.
If you DON'T need a SSL/TLS type connection (so evernode can resolve to http://) you can state --ssl--false. This is optional, because you may have your OWN SSL proxy before it's routed to the evernode.
also there is --proxyssl--false, this is for the internal connect from proxy to instance (default is always true).
you cannot specify BOTH a domain and subdomain, also if none are stated, a default sub-domain is created dependant on instance slot.
/contract/tls/cert.pem/contract/tls/privkey.pem/contract/tls/chain.pem/contract/tls/fullchain.pem/contract/tls/domain_ssl_update.logAnd just a FYI: The "hosts" TLS/SSL files are still provided at:
/contract/cfg/tlscert.pem/contract/cfg/tlskey.pemwebsite hosting example:
everweb/webcbuilder:latest--domain--yourdomain.com
uses the image everweb/webcbuilder for website hosting, and use your own domain (yourdomain.com) for the address
Yes, "Environment variables" will also be added to the docker instance to allow their use within the entry point script that's set within the docker image.
Needs to be within the start.sh/entrypoint.sh or child processes to be used.
OR they are also written to file /contract/env.vars so that you can source /contract/env.vars. This is also pre-sourced in the file .bashrc for terminal use.
$HOST_DOMAIN_ADDRESS$CUSTOM_DOMAIN_ADDRESS$EXTERNAL_PEER_PORT$INTERNAL_PEER_PORT$EXTERNAL_USER_PORT$INTERNAL_USER_PORT$EXTERNAL_GPTCP1_PORT$INTERNAL_GPTCP1_PORT$EXTERNAL_GPUDP1_PORT$INTERNAL_GPUDP1_PORT$EXTERNAL_GPTCP2_PORT$INTERNAL_GPTCP2_PORT$EXTERNAL_GPUDP2_PORT$INTERNAL_GPUDP2_PORT$RAM_QUOTA$DISK_QUOTA the following disk variables get updated every 15 minutes$DISK_QUOTA_BYTES$DISK_USED_BYTES$DISK_USED$DISK_FREEplus all additional --envX that was set will also be written here too.
Using environment variables:
source /contract/env.vars
Or access them directly in your scripts:
echo $HOST_DOMAIN_ADDRESS
echo $EXTERNAL_USER_PORT
Yes, you can use docker secret paths within your images /run/secrets/name
there are 4 default secrets that are created on all instances, which can be used, and are pre populated as placeholder-only initially
userpassurlkeyplus all additional --secX that are set
these secrets are then set AFTER the image is running, on this landing page.(these options/features are only available if you are logged in for that instance)
you use the drop down select menu to select the secret you want to set, and submit you new value.
values for your secrets can ONLY be set, and not read. due to security.
Security is important here, so by default when you use site to update, 1st a requests API is sent, and the docker-build hash file values, along with a key pairing check from the evernode itself is sent back.
if ANY of these fail, then security is questionable, and the (encrypted) secret is not then sent. this check can be overridden via the "CheckHash" toggle, which is YOUR decision to make. (toggle is provided for fallback, and testing)
also of note here is the authorization plugin layer that is enabled by default, this docker Auth plugin blocks all suspspictous commands, like exec, attach, cp.
you can check these Auth plugin logs for via the "Auth logs" button, enabling you to see LIVE if the Auth layer is; 1, enabled and LIVE, 2, check exec command is blocked (checking logs after executing a command on form), compare with and without the --debug--true option flag, as you can see Auth logs difference before and after events, as very hard to fake all these logs and outputs, along with correct time stamps.
More in depth details: a POST request is made to the api endpoint of this evernode at /api with data field { randomKey: a-random-key, type: integrity } a reply with signature and hash file results is then sent back, with this signature (using random key and hash results), your client verifys this with the held public key.
without the evernode having the secret key, and a unmodified API, and docker build files, its signature cannot be verified with public key, and if they are not verified, then with those files not in a good state, so the secret is then not 100% safe, so is not sent.
the api file hash should be,unknown
the docker build hash should be,unknown
and the public key for the key pair check is,unknown
Using secrets variables:
cat /run/secrets/user
please use best practices handling these secrets in scripts, only use them in memory, and clear memory after use, never write them to file.
you can use cat /run/secrets/user within the "execute" form on landing page (if --debug--true is set of course)