![\"A](\"https:\/\/devblogs.microsoft.com\/ise\/wp-content\/uploads\/sites\/55\/2023\/12\/dapr-architecture.png\")
<\/p>\nBuilding Java distributed applications leveraging Dapr provides a\npowerful yet simple way of harnessing your microservice solution with\nthe best and proven patterns, practices, and technologies around service\ndiscovery, message broker integration, encryption, observability, and\nsecret management. This allows you to focus on your business logic and\nkeep your code clean and tech-agnostic making use of the depth and\nbreadth of the Java ecosystem.<\/p>\n
While implementing a single application can be easily coded, tested, and\ndebugged locally or even using a single dev-container with all the\npreconditions already installed in it, modern cloud and serverless\narchitectures often require developing several decoupled independent\ncomponents\/applications that interact with each other applying pub\/sub,\nmessage-oriented, or event-driven patterns. Scaling your local dev\nenvironment accordingly so that you can spin up, debug, and test a\ncomplex solution of independent yet integrated applications speedily and\nreliably becomes an imperative issue to solve if you don’t want to spend\nhalf of the development time just configuring and setting up multiple\nrunning applications on your developer box.<\/p>\n
You will need to consider that each of these applications can be\ndeveloped utilizing different programming languages, will require the\nDapr “sidecar,” and can have unique backend integration dependencies, as\nshown in the following diagram:<\/p>\n
<\/p>\n
Dapr is a modern framework built to support cloud-native and serverless\ntechnologies. It is especially useful for deploying applications on top\nof Kubernetes or Azure Functions, acting like a pod sidecar\/agent. It\nbrings a highly modular and decoupled mindset that can be extended to\nthe Docker ecosystem. This key principle means that everything can be\ntranslated into a container, including your development environment.<\/p>\n
If your solution is composed of only Dapr applications with no dependent\ninfrastructure services, or if these dependencies are already deployed\nor accessible within your dev environment, or even if you just want to\nsplit the way you deploy things you may want to consider Dapr’s\nMulti-App run template file<\/a>.\nWith Multi-App Run, you can start many applications in self-hosted mode\nexecuting a single\u00a0 Some possible tradeoffs applying this approach are:<\/p>\n You still need to install\/deploy all dependencies and services\nmanually, leveraging docker-compose or some other way.<\/p>\n<\/li>\n You can’t do network config, manage replicas, or set a devcontainer\nusing the Dapr multi-app run file.<\/p>\n<\/li>\n You may end up exploiting different deployment strategies which will\nmake it harder and awkward to maintain and more prone for errors\n(specially for new developers jumping into the code for the first\ntime)<\/p>\n<\/li>\n<\/ul>\n The rest of this article focuses on the Docker compose approach\nexclusively.<\/p>\n Being able to spin up a multi-application development environment in\na matter of minutes instead of hours\/days.<\/p>\n<\/li>\n The only precondition is having VS Code and Docker installed or\nhaving GitHub’s Codespaces available.<\/p>\n<\/li>\n Being able to automatically spin up all infrastructure services like\ndatabases, observability platforms, supporting APIs, or messaging\nservices as part of the environment.<\/p>\n<\/li>\n Being able to hit breakpoints on Java applications that depend on or\nintegrate with daprd or the Dapr Java SDK.<\/p>\n<\/li>\n Avoid paying IDE licensing.<\/p>\n<\/li>\n<\/ul>\n The main Docker compose settings revolve around properly configuring\nDaprd integration with each of the Java Apps. This includes:<\/p>\n Below is an example of just the placement service, one Java App called\naccount-service and its correspondent Dapr sidecar:<\/p>\n Modify your Dapr Components URL routing to match the extra-host defined\nin your Docker compose file. In the following example, we modified the Each Java app has a We use the To enable it add this section to the devcontainer.json file:<\/p>\n Moreover, we included some extensions whose are helpful for developing\nJava applications. The one you really need to debug the app is the VS\nCode extension pack for java<\/strong>: Dapr run -f<\/code>\u00a0command employing a template file.\nThe template file describes how to start multiple applications as if you\nhad run separate CLI\u00a0run commands.<\/p>\n\n
Goals<\/h2>\n
\n
Detailed Approach<\/h2>\n
High level approach<\/h3>\n
\n
\n
extra-host<\/code> property in each Java app docker-compose\ndefinition, allowing them to access resources at the root\nlocalhost container level.<\/li>\n<\/ul>\n<\/li>\n127.0.0.1<\/code> or localhost<\/code>\nwon’t work to reach resources at the host level.<\/li>\n\n
\n
ENTRYPOINT<\/code>, enable Java remote debugging.<\/li>\n<\/ul>\n<\/li>\nDocker Compose<\/h3>\n
\n
network_mode<\/code> settings matching the Java app network namespace on the\nDapr sidecar and checking that all ports match.<\/li>\nDAPR_HTTP_PORT<\/code>, APP_PROTOCOL<\/code>, DAPR_GRPC_PORT<\/code>. Values will depend on\nyour specific Dapr configuration.<\/li>\n\"host.docker.internal:host-gateway\"<\/code> in order for Dapr to be able\nto access services at other containers and the localhost root\ncontainer service. See: How do I connect to the localhost of the machine? –\nStack Overflow<\/a>.<\/li>\nDockerfile<\/code> within the context folder. This\nDockerfile<\/code> is explain in the next section.<\/li>\n<\/ul>\n placement:\r\n image: \"daprio\/dapr\"\r\n command: [\".\/placement\", \"--port\", \"50006\"]\r\n ports:\r\n - \"50006:50006\"\r\n\r\n account-service:\r\n image: account-service:latest\r\n build:\r\n context: \".\/api\/account\"\r\n dockerfile: Dockerfile.dev\r\n environment:\r\n - LOGGING_LEVEL_ROOT\r\n - SERVER_PORT=8082\r\n - DAPR_HTTP_PORT=3601\r\n - APP_PROTOCOL=HTTP\r\n - DAPR_GRPC_PORT=60001\r\n depends_on:\r\n - redis\r\n ports:\r\n - \"60001:60001\" # Dapr instances communicate over gRPC so we need to expose the gRPC port\r\n - \"3601:3601\"\r\n - \"8082:8082\"\r\n - \"5005:5005\"\r\n extra_hosts:\r\n - \"host.docker.internal:host-gateway\"\r\n\r\n account-service-dapr:\r\n image: \"daprio\/daprd:1.11.2\"\r\n command: [\r\n \".\/daprd\",\r\n \"--app-id\", \"account-service\",\r\n \"--app-port\", \"8082\",\r\n \"--dapr-grpc-port\", \"60001\",\r\n \"--resources-path\", \".\/components\",\r\n \"--placement-host-address\", \"placement:60001\" # Dapr's placement service can be reach via the docker DNS entry\r\n ]\r\n volumes:\r\n - \".\/components\/:\/components\" # Mount our components folder for the runtime to use. The mounted location must match the --resources-path argument.\r\n depends_on:\r\n - redis\r\n environment:\r\n - SECRET_redis-password=\"\" # Using an empty password for this example, but you could set a password here and inject it into a .env file or a key-vault store\r\n network_mode: \"service:account-service\" # Attach the account-service-dapr service to the account-service network namespace\r\n<\/code><\/pre>\nModify your Dapr Components to route resources<\/h3>\n
\"127.0.0.1\"<\/code> or localhost<\/code> won’t work to\nreach resources at the host level in Linux environments like Codespaces.<\/p>\nredisHost<\/code> value from\n\"localhost:6379\"<\/code> to \"0-initialize-redis-1:6379\"<\/code> mapping the DNS routing\nassigned to Docker to the Redis<\/code> service. It does that by starting at the\nroot directory where the docker-compose.yaml file is located, named\n“0-initialize”<\/strong>, the name of the service “redis”<\/strong> and the replica, which\nis just “1”<\/strong> in this case.<\/p>\napiVersion: dapr.io\/v1alpha1\r\nkind: Component\r\nmetadata:\r\n name: account-database-binding\r\nspec:\r\n type: bindings.redis\r\n version: v1\r\n metadata:\r\n - name: redisHost\r\n value: \"0-initialize-redis-1:6379\"\r\n....<\/code><\/pre>\nJava App Dockerfile<\/h3>\n
Dockerfile<\/code> based out on the Maven, OpenJDK18 image,\nthus allowing a mvn clean install<\/code> to run seamlessly. Another significant\naspect is the \"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005\"<\/code>\nthat enables Java to expose its remote debugging port for external\nprocesses to attach to. In this example is 5005<\/strong> but you may need to make\nsure each App exposes a different port to avoid conflicts.<\/p>\nFROM maven:3.8.5-openjdk-18-slim\r\n\r\nWORKDIR \/src\r\nCOPY . .\r\n\r\nRUN mvn clean install -e -f \"pom.xml\"\r\n\r\nENTRYPOINT [\"java\",\"-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005\", \"-Dspring.profiles.active=localdocker\",\"-jar\",\"target\/account-0.0.1-SNAPSHOT.jar\"]\r\n<\/code><\/pre>\nDevcontainer<\/h3>\n
docker-in-docker<\/code> feature. This will enable to create child\ncontainers inside a container, independent from the host’s docker\ninstance. For more information find the official docker-in-docker documentation<\/a>.<\/p>\n\"features\": {\r\n \"ghcr.io\/devcontainers\/features\/docker-in-docker:2\": {}\r\n}<\/code><\/pre>\n\"vscjava.vscode-java-pack\"<\/code>, including\nthe debugger for Java among other useful language tools.<\/p>\n \"extensions\": [\r\n \"ms-azuretools.vscode-docker\",\r\n \"humao.rest-client\",\r\n \"cweijan.vscode-mysql-client2\",\r\n \"vscjava.vscode-java-pack\",\r\n \"ms-azuretools.vscode-dapr\"\r\n ]<\/code><\/pre>\n