- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- Administrator's Guide
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
Private Actions are in Preview. Use this form to request access today.
Request AccessPrivate actions allow your Datadog workflows and apps to interact with services hosted on your private network without exposing them to the public internet. To use private actions, you must install a private action runner on a host in your network using Docker or Kubernetes and pair the runner with a connection.
When you first start the runner, it generates a private key for authentication with Datadog’s servers. This private key is never accessible by Datadog and ensures you exclusive access. Datadog uses a public key derived from the private key as the means to authenticate specific runners.
A private action runner can be used with App Builder, Workflow Automation, or both.
The following is a general overview diagram for private actions:
The following table explains some distinctions between App Builder and Workflows modes, including their triggering mechanisms and operational models.
Distinction | App Builder mode | Workflows mode |
---|---|---|
Trigger mechanism | Human-driven - each action is initiated by user interaction with an App | Can run automatically without direct human intervention |
Trigger model | Push model - actions are triggered by directly accessing a URL on the runner | Pull model - periodically checks for tasks to execute |
Data handling | Keeps data in your private environment and does not send it to Datadog | Reports the result of private action executions to Datadog |
The difference in models can result in varying latencies. App Builder mode’s push model might lead to more immediate responses, whereas the pull model in Workflows mode might introduce delays based on polling frequency.
When your private action runner is in App Builder mode, queries that call your private services are sent directly from the user’s browser to the private action runner, which proxies requests to your services. At no point does your data enter Datadog when the runner is in App Builder mode; it communicates with Datadog only for enrollment and authentication purposes.
In the following diagram, App Management refers to backend App Builder actions that are unrelated to the Private Action runner, such as deleting an app.
To ensure secure communication, the Datadog frontend sends a single-use scoped token with each request, which the runner validates using a private key. This mechanism ensures that your data remains within your network and does not enter Datadog while maintaining the integrity and security of your private actions.
In App Builder mode, the user’s browser talks directly to your private action runner. As a result, you must specify a custom domain name that points to your runner. To set up your domain, point an A
or CNAME
record to your network’s ingress. Your ingress must be capable of terminating HTTPS requests and forwarding them to the runner container on port 9016. The domain and ingress do not have to be accessible to the public internet; the A
or CNAME
record can point, for example, to a load balancer that is only accessible through your company’s VPN.
If your private action runner runs in Workflows-only mode, you do not need to perform any setup beyond the initial enrollment. The private action runner continuously polls for tasks from your Datadog account, executes them by interacting with your internal service, and reports the result back to Datadog.
When you select the option to use both modes, the runner dynamically adjusts the mode it uses based on the type of request it receives. This ensures smooth operation whether the runner is handling app requests, Workflow Automation executions, or a combination of both.
추가 유용한 문서, 링크 및 기사: