When developing a Node JS project for an API you will find yourself needing a couple of local endpoints for storing your files or accessing a database for example. Usually you'll either use a remote api made accessible to you by your team's DevOps or a local instance of the service running on Docker or Minikube. This approach comes with a few drawbacks: * The image configuration is specific to your machine and configuration, it is not versioned therefore any changes mande by the rest of your team will not be reflected locally. * You have to manually run and maintain a Docker compose and expose the port to your app ## Servable System Design for Docker is here to help Servable helps you by: * Letting you define on your protocol the system requirements for running not only your current Servable app, but also the extra services you need in a Docker compose file * By including the Docker compose file in the protocol, you make it de facto versioned and available to the rest of the team and the community * When Servable launches it automatically runs the desired Docker Compose configuration and stores all the files associated in the root of your Servable project at `.system`. * The `.system` folder is not versioned therefore what data you use for mocking or testing your API stays local * The `.system` folder can be backed up easily by copying it all along or sent to your peers to kickstart their development. It can also be versioned on your git repository even though we don't recommend it. * Servable automatically detects used ports and increments the target ports until a free published port is assigned. The resulting docker-compose will be stored at `.system//docker-compose.yaml` ![](https://cdn.adoucoure.com/assets/mNw5VN8vVZVLSuQYwcjyh/_2024-09-30-09-05-28.webp) The docker compose file in the /< protocol >/system/docker folder. Here's an example of an app's design system: ```yaml services: app-cdn: image: bitnami/minio:latest restart: always ports: - 9010:9000 - 9011:9001 environment: MINIO_ROOT_USER: "MINIO_USERNAME_TO_CHANGE" MINIO_ROOT_PASSWORD: "MINIO_PASSWORD_TO_CHANGE" MINIO_SERVER_ACCESS_KEY: "<%= CHEATSHEET_MINIO_ACCESS_KEY %>" MINIO_SERVER_SECRET_KEY: "<%= CHEATSHEET_MINIO_SECRET %>" MINIO_DEFAULT_BUCKETS: "cheatsheets" volumes: - ./minio:/data x-servable-disabled: false app-extra-mongo: image: mongo restart: always command: mongod --bind_ip_all environment: MONGO_INITDB_ROOT_USERNAME: "<%= APP_MONGODB_USERNAME %>" MONGO_INITDB_ROOT_PASSWORD: "<%= APP_MONGODB_PASSWORD %>" MONGO_INITDB_DATABASE: "<%= APP_MONGODB_DATABASE %>" ports: - 27017:27017 volumes: - ./mongo/:/data/db mongo-gui: container_name: "mongo-gui" image: ugleiton/mongo-gui restart: always ports: - 4321:4321 environment: MONGO_URL: "mongodb://localhost:<:= app_extra_mongo_27017 :>" x-servable-disabled: true ``` In this example we have defined: * a minio deployment for storing files * a mongo database (note that this database is different from the one used by the engine) * a disabled mongo user interface for managing the mongo database We can enable it by setting the custom servable docker var to false or by removing it: ```yaml ... x-servable-disabled: false ``` ## Process env binding In the previous example we have bound the `app-extra-mongo` environment to the env vars `APP_MONGODB_USERNAME`,`APP_MONGODB_PASSWORD` and `APP_MONGODB_DATABASE`. This happens automatically by using the ejs template "<%= MY\_ENV\_VAR %>". At runtime you will access your variable with usual `process.env.MY_ENV_VAR` This helps keep your code unchanged between environments and avoid undefined variables when moving from one evironement to another. ## Published port binding In the previous example the `mongo-gui` deployment's `MONGO_URL` is pointing to the published `app-mongo` 27017 port, which can be different if the port is already used. That is the reason for this custom binding template ejs template "<%= MY\_DEPLOYMENT:DESIRED\_PUBLISHED\_PORT %>". Note: '-' need to be replaced by '\_' in the template. ### Note * It is recommended to declare services only in the docker-compose file. The version, the network and the name will be defined by Servable on runtime *

About