CloudNet v3 | The Cloud Network Environment Technology 3.3.0-RELEASE Hurricane

Tested Minecraft Versions:

• 1.8
• 1.9
• 1.10
• 1.11
• 1.12
• 1.13
• 1.14
• 1.15

Source Code:

https://github.com/CloudNetService/CloudNet-v3

Contributors:

Dytanic, juliarn, derrop

Languages Supported:

German

This project is being developed by CloudNet teammembers and the community via GitHub, see a list of contributors here.
Please don't use the reviews for questions/issues, use the discussion tab instead, create an issue on GitHub or join our discord for support.

What is CloudNet Tsunami?

CloudNet is an alternative application that can dynamically and easy deploy Minecraft oriented software. It should greatly simplify the work and the technical processes within a Minecraft server network or with standalone servers. The program should be the basis for a Minecraft network. With a very extensive API and a very modular architecture, the program should be easily extensible in all its capabilities. It should be a solution to the most creative ideas that brighten our Minecraft world. From minigame networks, CityBuild servers to private servers with CloudNet is the work low. If it needs to be developed for CloudNet, it will provide an API (Driver) that can be used to develop Bukkit / Sponge / Nukkit plugins or to develop modules to extend the core system. The application wrapper for the JVM allows support for a wide variety of Minecraft server software and allows direct inclusion of the API to retain it throughout the lifetime of the application.

CloudNet is the next generation of Minecraft Java and Bedrock cloud systems. The software is currently stable. You can use it for a productive network.

Development versions

All recent development builds can be found on our CI server: https://ci.cloudnetservice.eu/job/CloudNetService/job/CloudNet-v3/job/development/
While these fix bugs from earlier versions and contain new features, they haven't been tested yet and might contain issues. It's not recommended to use them in production.

To use a development version, just replace your launcher.jar file with the new launcher downloaded from our CI server.
The new launcher supports automatically downloading of new development versions. To enable this, first delete the launcher.cnl file and restart CloudNet.
After this, the cloudnet.cnl file will contain new properties. One is called "use-snapshots", which will, when set to true, check for new development versions on every start and will download and start them.

Features

• Plug&Play
• Lightweight runtime launcher for multiple versions or easy development on CloudNet
• Installer of dependencies
• Module system with default modules
• User management system with roles
• Easy server management with simple commands
• Tasks to classify the services
• Internal database system based on H2
• Multi group and configuration
• Dynamic Template Storage System
• Dynamic Deployment System
• Dynamic File inclusions for services with HTTP/HTTPS support
• Static services support for Projects like CityBuild or Vanilla
• Live updating and working in a cluster
• Smart service instance deployments in cluster
• New non blocking service console log caching without BungeeCord timeouts and infinity console streams
• A fast HTTP/HTTPS server
• A RESTful API
• SSL/TLS support for security connections between the nodes in cluster or between the services and the node with or none own certificates
• Multi root support and synchronizing in a network cluster
• Support for Minecraft vanilla 1.0+
• Application support for Nukkit Project 1.0+ for Bedrock Edition 1.7
• Application support for Bukkit based Minecraft 1.8.8+ (Spigot, PaperSpigot and more)
• Application support for Sponge based Minecraft servers with the SpongeAPI 7.0.0+
• Application support for BungeeCord proxy server and forks for MC 1.8.8+
• Application support for GlowStone minecraft server for MC 1.8.9+
• Application support for Velocity proxy server
• Application support for Waterdog proxy server for bedrock edition
• A every powerful API for
  asynchronously programming or
  synchronously programming
• A Bridge module, which includes the basics for the Bukkit, Sponge, BungeeCord and Nukkit API and for BungeeCord a /cloudnet command to dispatch the console of CloudNet ingame
• BungeeCord exploit protection with the Bridge Module for BungeeCord MC 1.8.8+
• Random Hub and /hub command with the Bridge Module for BungeeCord MC 1.8.8+
• /cloudnet command which dispatch the console of CloudNet Ingame for BungeeCord MC 1.8.8+
• A live, ingame, sorted signs system for Bukkit and Sponge with a dynamic animation and configuration for each group.
• A SyncProxy module, which include the synchronization between two or more BungeeCord services in one group.
• Motd layout configuration and synchronizing between Proxys with SyncProxy module
• Animated Tablist configuration with SyncProxy module
• - A Smart module for advanced configurations and automatic task management
• A Cloudflare module for dynamic adding and removing of DNS records for multi BungeeCord services
• A Report module Easily create reports to hear the services or node in the cluster and provide easy support.
• A Storage FTP/FTPS module to transport templates from an external server via FTP / FTPS
• A MySQL/MariaDB database support module as alternative central database for CloudNet data by other modules
• A Permissions Module which integrate the CloudNet user permissions system into the services plugin managers
  
• Memory management protection
• CPU management protection

Requirements

Minimal

• Java 8
• 128MB JVM Heap size
• 2GB DDR3 Memory
• 2 virtual cores
• Internet connection
• Advanced knowledge of your OS and Minecraft networks (Bukkit, BungeeCord etc.)

Recommended

• Java 11
• 512MB JVM Heap size
• 8GB DDR3 Memory
• 2-4 virtual cores
• Internet connection
• Advanced knowledge of your OS and Minecraft networks (Bukkit, BungeeCord etc.)

Setup

Default:

CloudNet should be started via the following script via Shell or a shell script.

Code (Text):

java -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops -Xmx512m -Xms256m -jar launcher.jar
 

After the installation of the cloud has been completed, you can now set up a simple network for Minecraft.

If there are no tasks yet, you can create the tasks "Lobby" and "Proxy".
Just execute the "tasks setup" command, it will lead you through the process of configuring the tasks the way you need them.

With the "tasks" command or in the /local/tasks.json file you can configure the tasks and groups, and add templates, deployments and inlcusions there.
If you use the configuration file, you should use the "reload config" command.

With the "create" command, you can now manually create a service based on a task.
You can also create custom services with "create new".

Code (Text):

create by Proxy 1 --start
create by Lobby 1 --start
 

The "service" command allows the administration of the created service.
The manual stop, start, restart and inform about a service in the cluster can invoke with this command.

If the bridge module is installed, you can join the pre-configuration directly to the lobby server via the BungeeCord server.

The further equipment is up to you!
Have fun!

Tutorials

Pume 3.0.0 Tsunami PRE [GERMAN] (Recommended)









TheMeinerLP Livestream 3.0.0 Tsunami PRE [GERMAN]



Components

Launcher

Spoiler: Description

The CloudNet launcher manages updating CloudNet, the installation of modules and dependencies.

Tasks

Spoiler: Description

Each task forms the "skeleton" of a service and its inclusions, templates, deployments, group affiliation etc.
Tasks are also used to identify the individual services running on the network.
However, apart from the type of service, they do not exactly describe which properties the individual application type possesses.

Tasks can be managed with the "tasks" command in CloudNet or in the "tasks.json" in the "local/" directory

Tasks can be created easily with the "tasks setup" command.

Services

Spoiler: Description

Services are basically just the programs CloudNet launches to create a Minecraft network. Services can be proxies or minecraft servers.
Services can either be created based on tasks, which contain the properties the services will have, or can be created completely from scratch.

Multi groups

Spoiler: Description

The groups are intended to summarize services and tasks. Each service can belong to one task and several groups.
Groups can add their own extra settings to the tasks as well as other groups, inclusions, deployments, templates.

As an example, there is the group lobby, the task "Lobby" and the task "PremiumLobby". Both tasks have membership of the group "Lobby".
In its configuration, the Lobby group determines that all tasks belonging to the "Lobby" group should also retrieve the templates local
with the prefix/folder "Lobby" and the name "all" and install them in the service.

Groups can be used by developers to extend the range of possibilities and abstraction of tasks.
There may be different types of tasks in a group, such as "Lobby" and "Bungee" in the "Global" group

Template Storage

Spoiler: Description

With the API, CloudNet allows the use of multiple template storage services to retrieve or deploy templates.
By default, the core of CloudNet brings the "local" template storage service.

Every service template that can be configured has a storage, ie the service from which the data is to be retrieved or transmitted.
The prefix is to set the namespace of the template in order to combine several templates within one namespace.
The name is the actual name of the template.

Code (Text):

        {  "prefix": "Lobby",    "name": "default",   "storage": "local" }

For each task, which is created with the "tasks" command, a
local template is also created. The local templates are always synchronized in the cluster.

Service management

CloudNet, provides very extensive features to manage the services in the cluster.
With the "create" command the services can be created manually.

Code (Text):

create new Lobby 1 minecraft_server templates=local:Lobby/default afterDeleteOnStop=false groups=Lobby,Global memory=356

or

create by Lobby 1
 

With the "--start" parameter, the registered and prepared services can automatically start automatically.
The created services can be managed in the cluster via the "service" command.

Show all services and some informations from one Task

Code (Text):

service list task=Lobby
 

Displayed, via the current information snapshots, you can via the UUID of the name. It is enough to write only a part of the respective one.
The info parameter also displays the plug-in and module information, which is transmitted via the bridge module in JSON.

Code (Text):

service Lobby-1
service 32bc1b46-a8ac-40cf-9fea-208984c61c7e

service Lobby-1 info
service 32bc1b46-a8ac-40cf-9fea-208984c61c7e info
 

Each service can be easily started, stopped, restarted and deleted.

Code (Text):

service Lobb start
service Lobby stop
service Lobby-1 stop --force
service 32bc delete
service L restart
 

You can run a command on a started service with the "command" parameter in the console.

Code (Text):

service Lobby-1 command say Hello Server!
 

In addition, you add templates and inclusions to a service.
And if the service is deleted, you can add additional deployments.

Code (Text):

service Lobby-1 add template local Lobby global
service Lobby-1 add inclusion https://hub.spigotmc.org/jenkins/job/spigot-essentials/10/artifact/Essentials/target/Essentials-2.x-SNAPSHOT.jar plugins/essentials.jar
service Lobby-1 restart
service Lobby-1 add deployment local Lobby SavedLobby
 

You can make persistable (static) services from one task to add a deployment

Code (Text):

tasks task Lobby add deployment local Lobby default

With the "screen" command, you allow the node to output the console output that is stored between and is output live from the application

Code (Text):

screen Lobby-1

Working with multiple nodes in a Cluster

The instances of CloudNet, also called Nodes, can be easily connected.
This allows tasks, groups, and local templates to synchronize with the network and distribute
the services to each node. With appropriate configuration, this can significantly increase the
overall resilience of the network. It also allows easy task distribution.

Each cluster has its own clusterId, which can be found in config.json.
It is important that all nodes in the cluster have the same "clusterId" in their configuration file.

All nodes in the network must be interconnected. There are no direct master / slave behaviors,
but only the rule that the node that connects to another node
gets the information from the already existing node and updates it. (Except the cluster configuration)

Spoiler: Description

Add a node in the cluster:

Adding new nodes can be done trough the "cluster" command or via the config.json file of the node.

Code (Text):

cluster add e760a2c3 127.0.0.1 1411

Not every node has to be online when using the cluster, but it's important to work with a central database (for example MySQL with the MySQL module) to avoid synchronization problems in the cluster. H2 should not be used. When all nodes are online, they synchronize all important information.

Update manual information:

Manual updating of cluster-relevant information can be achieved with the "cluster push" command. It sends specific data of the current node to all other nodes connected within the cluster.

Code (Text):

cluster push local-templates
cluster push local-perms
cluster push tasks
cluster push groups

Remove a node in cluster:

Removing nodes can be done trough the "cluster" command or via the config.json file of the node.

Code (Text):

cluster remove e760a2c3
reload confirm

The connection to the node will be closed.
It is recommended to restart the node.

How do modules work in the cluster?
CloudNet's default are fully designed to work in a cluster. Third-party modules aren't automatically compatible with working in a cluster, they have to include this support by themselves.

Default modules

Here is an introduction to the modules. These modules are the standard equipment.
These modules include the advanced functionality of CloudNet. They should be a
support for a Minecraft network to save a lot of their own technical developments or reduce the effort.

All standard modules that have a configuration have a config.json in each module's name folder.

Spoiler: Bridge module

The bridge module is the core of the modules. It connects servers with their proxies and manages fallbacks und Hubs.
It does also serve the ingame /cloud and /lobby commands.

The bridge module also contains "only proxy join", which prevents users from bypassing the proxy, which leads to direct access to the minecraft servers.
This is more of a protection for unexperienced users. Unwanted problems can occur when using this feature, we highly recommend to disable it entirely and to use a firewall instead. (Click here for a tutorial on firewalls).

Spoiler: Signs module

The sign system has a sorted animated, live updating sign system, depending on the order of occupation.
The tags can even be targeted to specific groups with a template path limitation.
The services as well as the sign system itself need the CloudNet bridge module, so
that the information for the presentation is available. Otherwise, the signs would
only show the servers as the starting phase.
With the /cloudsign command, the signs can be set or deleted while watching one of them.

Here is a list of patterns for the sign layout

Code (Text):

%task% - Name of task %task_id% - Current id from one task[/SIZE][/SIZE][/COLOR][/COLOR][/SIZE][/SIZE][/COLOR][/COLOR][/SIZE][/SIZE][/COLOR][/COLOR][/SIZE][/SIZE][/COLOR][/COLOR][/SIZE][/SIZE][/COLOR][/COLOR][/SIZE][/SIZE][/COLOR][/COLOR][/SIZE][/SIZE][/COLOR][/COLOR]
[COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4]%group% - The group which the sign has target
%name% - The readable Name of the service like "BedWars-1"
%uuid% - The first characters of the service uniqueId
%node% - The node from the service
%environment% - The environment type of the service which is configured
%life_cycle% - The current life_cycle type
%runtime% - The runtime process type
%port% - The current configured port of the service
%cpu_usage% - The current CPU usage of the service
%threads% - The current Thread count
%online% - Is the service online or not from the "Online" property in Bridge-Module
%online_players% - The current online count of the service
%max_players% - The max players size from the service
%motd% - The Motd of the service or the Text of the CloudNet-BridgeAPI
%extra% - The extra string text by the CloudNet-Bridge API
%state% - The state string text by the CloudNet-Bridge API
%version% - The current version of the service
%whitelist% - Request if the whitelist enabled or not[/SIZE]
 

Spoiler: SyncProxy module

The SyncProxy module is responsible for the pure representation of the motd and the tab list in order to
synchronize proxy services within a group. She also has a maintenance mode with a whitelist on it.
Above all, it is interesting when it comes to the use of multiple proxy services to distribute the players there.

Motd Patterns:

Spoiler: SyncProxy module

Code (Text):

%proxy% - The current proxy service name
%proxy_uniqueId% - The current proxy service uniqueId]
%task% - the current task name of the current proxy
%node% - the node uniqueId of the proxy

Tablist Patterns:
%proxy% - The current proxy service name
%proxy_uniqueId% - The current proxy service uniqueId
%server% - The server name which the player is connected
%online_players% - The current proxy online count
%max_players% - The max player size, which is configured is
%proxy_task_name% - The task from the proxy, which the player is connected
%name% - Name of the player which get the tab list[/code]

Spoiler: Smart module

The Smart Module adds configurations to the actual Task Configurations,
plus additional customizations adapted to the CloudNet Bridge Module.
Through this, processes that exist in CloudNet can be optimized for a
MiniGame network so that the need for game servers is optimally adapted to those of the players.

Spoiler: Cloudflare module

The Cloudflare Module allows automatic entry of Domain DNSRecords for larger required network capacities.
These can be made from any type of application, from bungee cord to normal vanilla servers, the group sets the tone.
For the configuration you need a domain and an account at the provider https://cloudflare.com.
Several domains with different users etc. can be managed, even for the same groups.
You need the email, the API key from the account (the global API key!), The ZoneId found on the domain's dashboard page.

The "@" wildcard in the "sub" configuration of a group determines that it does not become
a subdomain that owns a third-level domain, but only a second-level domain.

The configuration must be set up in the cluster at each node individually, so that one can avoid unintentional entries such as
nodes that are within an internal LAN and can only be reached via specific ports or proxy servers.

Spoiler: Storage FTP/FTPS module

The module allows a TemplateStorage to connect to a remote server with either FTP or FTPS. For this, the current file path is still required in the configuration. The structure of the templates is similar to that of the Local Template System, except that the default storage name is "ftp". However, this can be changed in the config.json of this module. Basically, the module needs a proper basic configuration to use it. The use of the template storage "ftp" could lead to immediate errors without previous configuration.

Development

Java documentation
https://cloudnetservice.eu/cloudnet/docs/v3.3.0-RELEASE/

Maven:

Code (Text):

<!--  New Maven repository for releases -->
<repository>
    <id>releases</id>
    <url>https://repo.cloudnetservice.eu/repository/releases/</url>
</repository>

<!--  New Maven repository for snapshots -->
<repository>
    <id>snapshots</id>
    <url>https://repo.cloudnetservice.eu/repository/snapshots/</url>
</repository>


<!-- Modules and plugins -->

<!--  cloudnet application for modules (NOT AVAILABLE FOR PLUGINS!) -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>

<!--  cloudnet driver for plugins and modules -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet-driver</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>

<!--  cloudnet wrapper for plugins -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet-wrapper-jvm</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>

<!--  cloudnet bridge module for plugins and modules -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet-bridge</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>

<!--  cloudnet syncproxy module for plugins (proxy) and modules -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet-syncproxy</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>

<!--  cloudnet signs module for plugins and modules -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet-signs</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>

<!--  cloudnet npcs module for plugins and modules -->
<dependency>
    <groupId>de.dytanic.cloudnet</groupId>
    <artifactId>cloudnet-npcs</artifactId>
    <version>3.3.0-RELEASE</version>
    <scope>provided</scope>
</dependency>
 

Screenshots

Spoiler: Screenshots

Signs-Module



SyncProxy-Module