SVI/netbird
1
0
Fork 0
mirror of https://github.com/netbirdio/netbird.git synced 2026-05-19 14:41:58 -04:00
Code Issues 3.0k Packages Projects Releases 10 Wiki Activity

Netbird Signal Container does not run on AWS ECS due to missing binaries. #589

New Issue
Closed
opened 2025-11-20 05:14:14 -05:00 by saavagebueno · 3 comments
saavagebueno commented 2025-11-20 05:14:14 -05:00
Owner
Copy Link

Originally created by @joshuahigginson1 on GitHub (Jan 17, 2024).

Describe the problem
When trying to run the dockerhub container on Amazon ECS, the distroless container backing netbird signal does not launch. It errors with an unidentifiable error message (This is a separate AWS issue.)

The container runs absolutely fine after re-building the image with the following Dockerfile:

# Use AWS Bottlerocket as the base image.
FROM amazonlinux:latest

# Set the working directory
WORKDIR /app

# Copy the netbird-signal binary from the original image.
COPY --from=netbirdio/signal:0.25.4 /go/bin/netbird-signal /app/netbird-signal

# Ensure ownership of the file for the nobody user.
RUN chown nobody:nobody /app/netbird-signal && chmod +x /app/netbird-signal

# Set the entry point and default command.
ENTRYPOINT [ "/app/netbird-signal", "run" ]
CMD ["--log-file", "console"]

# Specify a non-root user
USER nobody

Perhaps it would be worth updating the base image to support AWS fargate functionality off the bat.
To Reproduce
Steps to reproduce the behavior:

  1. Deploy on AWS ECS using the current container held inside of dockerhub - netbirdio/netbird:0.25.4

Expected behavior
A clear and concise description of what you expected to happen.

  1. Error logs should stream like so:
    image

NetBird status -d output:
If applicable, add the output of the netbird status -d command

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Originally created by @joshuahigginson1 on GitHub (Jan 17, 2024). **Describe the problem** When trying to run the dockerhub container on Amazon ECS, the distroless container backing netbird signal does not launch. It errors with an unidentifiable error message (This is a separate AWS issue.) The container runs absolutely fine after re-building the image with the following Dockerfile: ``` # Use AWS Bottlerocket as the base image. FROM amazonlinux:latest # Set the working directory WORKDIR /app # Copy the netbird-signal binary from the original image. COPY --from=netbirdio/signal:0.25.4 /go/bin/netbird-signal /app/netbird-signal # Ensure ownership of the file for the nobody user. RUN chown nobody:nobody /app/netbird-signal && chmod +x /app/netbird-signal # Set the entry point and default command. ENTRYPOINT [ "/app/netbird-signal", "run" ] CMD ["--log-file", "console"] # Specify a non-root user USER nobody ``` Perhaps it would be worth updating the base image to support AWS fargate functionality off the bat. **To Reproduce** Steps to reproduce the behavior: 1. Deploy on AWS ECS using the current container held inside of dockerhub - netbirdio/netbird:0.25.4 **Expected behavior** A clear and concise description of what you expected to happen. 1. Error logs should stream like so: <img width="810" alt="image" src="https://github.com/netbirdio/netbird/assets/65719561/15cc702b-6fb8-416b-9200-cfb4b784f2b7"> **NetBird status -d output:** If applicable, add the output of the `netbird status -d` command **Screenshots** If applicable, add screenshots to help explain your problem. **Additional context** Add any other context about the problem here.
saavagebueno added the bugthird-party-integration labels 2025-11-20 05:14:14 -05:00
saavagebueno commented 2025-11-20 05:14:15 -05:00
Author
Owner
Copy Link

@lixmal commented on GitHub (Jan 18, 2024):

Hi @joshuahigginson1,

I've tested the image (both netbird and signal) on fargate, but both worked fine without issues.
The images don't have any dependencies.

Can you share more information about your setup?
What was the CPU arch that you used for the task definition?

@lixmal commented on GitHub (Jan 18, 2024): Hi @joshuahigginson1, I've tested the image (both `netbird` and `signal`) on fargate, but both worked fine without issues. The images don't have any dependencies. Can you share more information about your setup? What was the CPU arch that you used for the task definition?
saavagebueno commented 2025-11-20 05:14:15 -05:00
Author
Owner
Copy Link

@joshuahigginson1 commented on GitHub (Jan 18, 2024):

Hi @lixmal, we have had no issues whatsoever with the netbird management container. Task def is below. Working totally fine with the dockerfile provided above, but when switching out the signal container for that hosted within dockerhub, no dice.

As no logs were streaming, I believed that it was due to the lack of the awslogs binaries in distroless container.

  ECSTaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      # Similar to a name, used for grouping multiple revisions of the task definition.
      Family: "netbird-signal-ecs-task-family"

      Cpu: 512
      Memory: 1024

      NetworkMode: awsvpc
      RequiresCompatibilities:
        - FARGATE

      RuntimePlatform:
        OperatingSystemFamily: LINUX
        CpuArchitecture: ARM64

      TaskRoleArn: !GetAtt ECSTaskRole.Arn
      ExecutionRoleArn: !GetAtt ECSTaskExecutionRole.Arn

      ContainerDefinitions:
        - Name: "netbird-signal"
          # Defines that this container is the 'Main' container. If this fails, every other container will stop.
          Essential: true
          Image: !Sub "${NetBirdContainerRepository}:${NetBirdContainerVersion}"
          
          LogConfiguration:
            LogDriver: awslogs
            Options:
              awslogs-group: !Ref ECSTaskLogGroup
              awslogs-region: !Ref AWS::Region
              awslogs-stream-prefix: signal

              # Prevent log loss in event of network error.
              mode: "non-blocking"
              max-buffer-size: "25m"

          # Here, we are telling signal to run GRPC on port 10000. Note that we are using the NLB and AWS' own certificate to perform TLS.
          PortMappings:
            - Name: "signal-grpc-port"
              ContainerPort: 10000
              HostPort: 10000
              Protocol: tcp

          Command: ["--log-file", "console", "--port", "10000"]
@joshuahigginson1 commented on GitHub (Jan 18, 2024): Hi @lixmal, we have had no issues whatsoever with the netbird management container. Task def is below. Working totally fine with the dockerfile provided above, but when switching out the signal container for that hosted within dockerhub, no dice. As no logs were streaming, I believed that it was due to the lack of the awslogs binaries in distroless container. ``` ECSTaskDefinition: Type: AWS::ECS::TaskDefinition Properties: # Similar to a name, used for grouping multiple revisions of the task definition. Family: "netbird-signal-ecs-task-family" Cpu: 512 Memory: 1024 NetworkMode: awsvpc RequiresCompatibilities: - FARGATE RuntimePlatform: OperatingSystemFamily: LINUX CpuArchitecture: ARM64 TaskRoleArn: !GetAtt ECSTaskRole.Arn ExecutionRoleArn: !GetAtt ECSTaskExecutionRole.Arn ContainerDefinitions: - Name: "netbird-signal" # Defines that this container is the 'Main' container. If this fails, every other container will stop. Essential: true Image: !Sub "${NetBirdContainerRepository}:${NetBirdContainerVersion}" LogConfiguration: LogDriver: awslogs Options: awslogs-group: !Ref ECSTaskLogGroup awslogs-region: !Ref AWS::Region awslogs-stream-prefix: signal # Prevent log loss in event of network error. mode: "non-blocking" max-buffer-size: "25m" # Here, we are telling signal to run GRPC on port 10000. Note that we are using the NLB and AWS' own certificate to perform TLS. PortMappings: - Name: "signal-grpc-port" ContainerPort: 10000 HostPort: 10000 Protocol: tcp Command: ["--log-file", "console", "--port", "10000"] ```
saavagebueno commented 2025-11-20 05:14:15 -05:00
Author
Owner
Copy Link

@joshuahigginson1 commented on GitHub (Mar 14, 2024):

Closing this issue, based on the fix above stable for 2 months.

@joshuahigginson1 commented on GitHub (Mar 14, 2024): Closing this issue, based on the fix above stable for 2 months.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
2021 Q4
2022 Q1
2022 Q1
accessibility
acl
agent
agent
Android
Android
api
authentik
automation
azure
battery-usage
bug
cache
client
client-ui
cloud
cloud-only
cloudflare
community
compatibility
config-idp
config-issue
connection
contribution
coturn
cross-vpn
dashboard
data-usage
distribution
dns
docker
documentation
duplicate
enhancement
enhancement
event-stream
feature-request
freebsd
getting-started
go
good first issue
gui
help wanted
home-assistant
idp
inconsistency
integration
integrations
ios
ipv6
jwt
k8s
keycloak
linux
login
macos
management-service
missing-docs
mobile
moved-internal
needs-review
netbird-ui
networking
new-platform
nginx
notification
okta
openwrt
packaging
peer-management
peer-management
peer-management
performance
postgres
posture-checks
psk
pull-request
Mirrored from GitHub Pull Request
 question
refactor
relay
release
rfc
routes
security
security-related
self-hosting
server
signal
sleep-issue
ssh
ssl
status
store
synology
system-compatibility-issue
test-suite
third-party-integration
triage
triage-needed
troubleshooting
UX
waiting-feedback
windows
wontfix
zitadel
No Label bug third-party-integration
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
saavagebueno
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: SVI/netbird#589
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?