Quick Start

A CloudI service written in C is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example C service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/c/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex C
examples are listed here.

A CloudI service written in C++ is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example C++ service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/cxx/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex C++
examples are listed here.

A CloudI service written in Elixir is called an "internal" service
because the service is ran inside the Erlang VM.
The example Elixir service can be created by executing the following
inside your shell:

Now compile the CloudI service module. If the CloudI
service needed to utilize other Elixir dependencies they would
be added to the mix.exs file.

mix compile

You now have a CloudI service contained within a single Elixir module
that may look familiar if you remember how a GenServer behavior works.
Instead of using the GenServer behavior, we are using a cloudi_service
behavior which provides more features with CloudI service requests.
To allow the Erlang VM to find the CloudI service Elixir module that has
been compiled, it is necessary to add the current directory to the
code path:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/elixir/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell.
The available service configuration parameters are described in
the services_add documentation.

A CloudI service written in Erlang (or using a language based on
core Erlang like Elixir) is called an "internal" service
because the service is ran inside the Erlang VM.
The example Erlang service can be created by executing the following
inside your shell:

Now compile the CloudI service module. If the CloudI
service needed to utilize other Erlang dependencies an Erlang/OTP .app
file would be added with the same filename
(see the examples for more details).

You now have a CloudI service contained within a single Erlang module
that may look familiar if you remember how a gen_server behavior works.
Instead of using the gen_server behavior, we are using a cloudi_service
behavior which provides more features with CloudI service requests.
To allow the Erlang VM to find the CloudI service Erlang module that has
been compiled, it is necessary to add the current directory to the
code path:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/erlang/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. To get more details on CloudI Erlang integration
(i.e., CloudI runtime usage with Erlang) see the
examples in the source code repository.
The available service configuration parameters are described in
the services_add documentation.
More complex Erlang examples are listed here.

CloudI must be compiled and installed after using the configure
argument "--enable-go-support" before attempting the Go quickstart
below:

A CloudI service written in Go is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example Go service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/go/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex Go
examples are listed here.

A CloudI service written in Java is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example Java service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/java/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex Java
examples are listed here.

A CloudI service written in JavaScript is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example JavaScript service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/javascript/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex JavaScript
examples are listed here.

A CloudI service written in Perl is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example Perl service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/perl/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex Perl
examples are listed here.

A CloudI service written in PHP is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example PHP service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/php/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex PHP
examples are listed here.

A CloudI service written in Python is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example Python service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(either python2 or python3 will work and the python executable name
may instead be "python" on your system):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/python/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex Python
examples are listed here.

A CloudI service written in Ruby is called an "external" service
because the service is ran inside an Operating System process
(external to the Erlang VM). The example Ruby service can be
created by executing the following inside your shell:

Now it is necessary to create the CloudI service configuration that
specifies both the initialization and fault-tolerance constraints
the CloudI service should be executed with
(with the proplist format to rely on defaults):

The curl requests have been using the cowboy HTTP server that is
running within the default CloudI configuration to allow the
CloudI Service API to be used over HTTP. The same HTTP server can
be used to make a CloudI service request to the hello_world service
with:

curl http://localhost:6464/quickstart/ruby/hello_world

If there was a problem during the service creation there would be an
ERROR entry within the /usr/local/var/log/cloudi/cloudi.log file.
If an error occurred with a curl command it would be displayed
in the shell. The available service configuration parameters are
described in the
services_add documentation.
More complex Ruby
examples are listed here.

The CloudI integration tests are now running and consuming your
available CPUs. The /usr/local/var/log/cloudi/cloudi.log file provides
integration test output. You can now select a programming language
above to create a CloudI service.