Synpse
🤖 Devices⚡ ApplicationsTry Synpse!
  • Intro to Synpse
  • Start here
    • Quick Start (web user)
    • Quick Start (CLI)
  • Agent
    • Install
      • Raspberry Pi
      • Linux (Docker)
      • MacOS
      • NVIDIA Jetson
      • Headless (Ubuntu)
      • BeagleBoard AI
      • Bulk Provisioning
      • 🪄Beta - Universal Synpse image
      • Containerized agent
      • Configuration
    • Uninstall
  • CLI
    • Install & Usage
  • synpse core
    • Devices
      • Device Provisioning
      • HTTPS Tunnel Access
      • SSH Access
      • Device Labels
      • Environment Variables
      • Proxy Application Ports
      • OS & Architectures
      • Operations
      • Device API
    • Applications
      • Deploy
      • Secrets
      • Environment variables
      • Substitution (dynamic templates)
      • Volumes
      • Networking
      • Scheduling
      • Registry authentication
      • Using GPUs
      • Tips & Tricks
      • Logs and status
      • Application specification (API reference)
    • Account
      • Personal Access Tokens
      • Service (Robot) Accounts
      • Teams (Share Devices)
    • Monitoring (beta)
      • Device Monitoring
      • Application Monitoring
  • Manage
    • Projects
    • Namespaces
    • Quotas
  • Examples
    • 🏠Home Automation
      • Gladys Assistant
      • Home Assistant
    • 🛠️Preparing OS Images
      • Synpse CLI Builder
      • Build a custom Raspberry Pi image
      • Cloud-init (advanced)
    • 💡Dynamic Templates
    • ☁️Public Cloud IoT
      • AWS IoT Core
      • Azure IoT Hub
      • GCP IoT Core
    • 🚀Device management
      • VNC to remove devices
      • Ansible
  • On-prem Deployment
    • 🐳Docker Compose
    • 🌤️kubernetes
  • Resources
    • API Documentation
    • Deployment patterns
    • Security & Tech
Powered by GitBook
On this page
  • Customizing network
  • Bridge network mode (default)
  • Host network mode
  • DNS
  • Port Mapping

Was this helpful?

  1. synpse core
  2. Applications

Networking

When deploying applications multiple network configurations are available (container to container and container to host services)

PreviousVolumesNextScheduling

Last updated 3 years ago

Was this helpful?

By default, all container in the application can communicate with each other based on their container names, for example:

name: metabase
description: Metabase + Postgres
scheduling:
  type: Conditional
  selectors:
    type: controller
spec:
  containers:
    - name: metabase
      image: metabase/metabase:latest
      ports:
        - 3000:3000
      restartPolicy: {}
    - name: postgres
      image: postgres:13.4

In this case, application can connect to Postgres database via postgres:5432 .

Customizing network

Network mode is configured within individual container specification:

name: networking
...
spec:
  containers:
    - name: network1
      networkMode: host # <- use host networking
      ports:
        - 8080 # <- expose 8080 port on host network
    - name: network2
      networkMode: bridge # <- use bridge networking (default)
      ports:
        - 8080:80 # <- map port 8080 from host to container port 80

Bridge network mode (default)

If no networkMode is provided container will be sharing default bridge for all containers:

name: my-app
...
spec:
  containers:
    - name: network1
      networkMode: host # <- use host networking
      ports:
        - 8080 # <- expose 8080 port on host network
...

‌If multiple containers are provided within application specification and bridge network is provided - containers will share networking.

name: my-app
...
spec:
  containers:
    - name: container1
      ...
      networkMode: bridge # <- both containers has bride network
      ports:
        - 8080 # <- expose 8080 port on host network
    - name: container2
      ...
      networkMode: bridge
      ports:
        - 8081 # <- expose differnet port, otherwise there will be a clash
...

​When using bridge networking with multiple containers custom hostname can be provided from applications to reach other containers. This is very useful when application need to communicate with other container, without exposing it.

For short names use option hostname . In the example bellow container hello-synpse-redis-go will be able to reach redis by calling http://redis:port

name: my-app
...
spec:
  containers:
  - name: app
    image: quay.io/synpse/hello-synpse-redis-go:latest
    networkMode: bridge
    ports:
    - 8080:8080
  - name: redis
    image: docker.io/redis:latest
    hostname: redis
    networkMode: bridge
...

Host network mode

host network mode will make containers use the same network as the device itself. This is useful when your application needs to connect to a server that's running on the device itself or a container that is on another Docker network.

name: networking
...
spec:
  containers:
    - name: network1
      networkMode: host # <- use host networking
      ports:
        - 8080 # <- expose 8080 port on host network
...

By running multiple containers on the same device there is chance for port clashes.

DNS

Individual containers DNS names can be specified with parameter hostname

name: networking
...
spec:
  containers:
  - name: redis
    image: docker.io/redis:latest
    hostname: redis
    networkMode: bridge
...

Port Mapping

Containers can expose ports to device by using port mapping configuration. It allows direct mapping or port translation.

name: networking
...
spec:
  containers:
  - name: network1
    ...
    ports:
    - 8080:80 # <- expose container port 80 on the device as port 8080
  - name: network2
    ...
    ports:
    - 8080 # <- expose port 8080 from container to device
Metabase