This document assumes that you have already compiled all services (i.e., you read all of the README.md from the top level folder and ran make services there) and now you want to see how it all fits together.
Use 2 different terminals and run:
# On terminal 1, start the dependencies
deploy/docker-ephemeral/run.sh
# On terminal 2, start the services
deploy/services-demo/demo.sh
conf <- folder with configuration for all services
└── nginz
├── nginx.conf <- main nginx configuration
├── ... <- other nginx config files
├── upstreams <- nginx upstream configuration
├── <service>.demo.yaml <- service configuration file (brig, cannon, cargohold, galley, gundeck, proxy)
resources <- folder which contains secrets or other resources used by services
├── templates <- email/sms/call templates used by brig
├── turn <- list of TURN servers available and a secret (autogenerated by demo.sh, used by brig and TURN server)
├── zauth <- public/private keys used for authentication (autogenerated by demo.sh, used by brig and nginz)
├── nexmo-credentials.yaml <- dummy credentials for the nexmo API (used by brig)
├── proxy.config <- dummy credentials for multiple proxied services (used by proxy)
├── twilio-credentials.yaml <- dummy credentials for the twilio API (used by brig)
├── create_test_user.sh <- bash script that creates a user and prints the credentials created
├── demo.sh <- bash script that generates needed secrets and starts all services
└── README.md <- this file
The way that the data stores used are set up is done in a simple way that is not advisable for a production environment (e.g., cassandra uses a single node and Docker will manage the storage of your database data by writing the database files to disk on the host system using its own internal volume management). Also, some other dependencies (such as the "fake" AWS services) do not provide the full functionality of the real AWS services (for instance, large resumable uploads are not supported) nor do they have the same reliability and availability.
It is however very straightforward to setup all the necessary dependencies to run wire-server and it is what we use in our integration tests as well (as can be seen in our integration bash script).
nginx: [alert] could not open error log file: open() "/var/log/nginz/error.log" failed (2: No such file or directory)
This is not really an issue and nginz is fine. nginz has a LOG_PATHcheck the Makefile defined which it always tries to write to during startup, even if you have defined a different path on your nginx.conf. You can safely ignore this warning or recompile nginz with a LOG_PATH which is writable on your system.
Yes. If all has been set up correctly, you should be able to navigate to http://127.0.0.1:8080/swagger-ui where you should be faced with a login screen that looks like
In order to view the API, you need to create a regular user. For that purpose, you can then run the script ./create_test_user.sh and use the credentials that you see on the screen to log in.
Short answer: yes and no. At the moment, you need one AWS service in order to test your cluster with our automated smoketester tool. The sesEndpoint in brig's example configuration needs to point to a real AWS SES endpoint.
In your environment, you can configure AWS_REGION, AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for your correct AWS account. Note that there are other ways to specify these credentials (to be detailed later).
Then, have a look at what the configuration for the api-smoketest should be. Once you have the correct mailboxes.json, this should just work from the top level directory (note the sender-email must match brig's sender-email)
# This assumes, for now, that brig is configured to use a real AWS SES endpoint
../../dist/api-smoketest --api-host=127.0.0.1 --api-port=8080 --api-websocket-host=127.0.0.1 --api-websocket-port=8081 --mailbox-config=<path_to_mailboxes_file> --sender-email=backend-integration@wire.com --enable-asserts