There are two ways to build and run the services - using docker compose
and using the make script
You can build and run them using docker
and docker compose
- this method will set everything up without the need to manually build the services and orcestrate them to run. To build and run the services this way, you need to know the following commands:
- Run
docker compose up --build -d
in the project's root folder. The last-d
flad tells docker to run them in detached mode, which means you can use the same console to test the services, too. - If running the services this way doesn't seem to work, then you can see what the logs for the different services are by running.
docker logs -f <container_id or container_name>
. You can get the names of the running containers usingdocker ps
(if you'd like to see all containers, including the stopped ones, then rundocker ps -a
alternatively). - If you encounter problems that a specific image is taken or being used, just run
docker system prune -a --volumes
to clean docker and follow step1.
Docker compose setup supports also the scaling up and down of the services it runs. For example, the default setup runs 1 instance of each service by default. However, if you'd like scale some service up, then you can do the following:
docker compose up --build --scale request-service=3 -d
In the above command, we tell docker compose to run 3 instances of request-service.
Another useful command with docker is
docker stats
This will show you realtime statistics for the running container and, if run in the above scenario, with the Browser Tests running as well, it will show you that the CPU of all the request-service containers go up indicating the load balancing is working properly and the requests are distributed between all three containers.
- Run
make.sh
(see Makefile extras below) - Go to
bin
- Start login service :
./user-service user-service.yaml
- Start request service:
./request-service request-service.yaml
5. Start game service:./game-service
5. [test] run(still possible but not recommended avoid it, use the mongo)./gen-players.sh
to insert 10 dummy players
Learn uber's zap logger and use it accordingly in the projectReplace all printlines withlogger.ZapperLog
and use it for everything- Recovery implementation
- History implementation
- Free games
1. Those are just a template usages of grpc
2. Use as reference not for final product we will need much more
3. Fixed also make to deal with those 2
- Run
./make.sh
with no args to build and update go modules of all projects - Run
./make.sh <branchname>
to build and update go modules frominternal-libs
on your branchname frominternal-libs
branch - Run
./make.sh -n
to only build projects with no update of go modules ofinternal-libs
(local build faster)
- run
./make.sh
- go to
bin
folder - modify
requests-service.yaml
to usesqlite3
instead ofmongo
if you are offline, otherwise leave unchanged. - run
./request-service request-service.yaml
- In case you use
sqlite3
option , run./gen-players.sh
to populate the local db with dummy players. run./game-service
or./game-service t
(t opiton os for the permuted reels test), no option is for random reels (original)- open in the browser
pay-histogram.html
and pressF12
for firefox to see the console log - You may watch the histogram in the canvas and track the rtp percentage in the console log.
multi-bet.html
creates 10 websocket clients that betting infinitely and also asks in 5 seconds for get players/winnerspay-histogram.html
- histogram of payments , bets infinitely with 100 on 1 id and plots the paytable
- We have to give a good seed per user session (not per game )
- Good approach is to seed mt19973 with dev/urandom or golangs embeded crypto/rand
- In real life 2 players will have different seeds so the deterministic output cannot be predicted avoiding bruteforce