惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

雷峰网
雷峰网
T
The Blog of Author Tim Ferriss
Scott Helme
Scott Helme
P
Proofpoint News Feed
D
Docker
The Hacker News
The Hacker News
云风的 BLOG
云风的 BLOG
Vercel News
Vercel News
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Project Zero
Project Zero
cs.CL updates on arXiv.org
cs.CL updates on arXiv.org
GbyAI
GbyAI
Jina AI
Jina AI
P
Proofpoint News Feed
P
Privacy & Cybersecurity Law Blog
T
Threat Research - Cisco Blogs
C
CERT Recently Published Vulnerability Notes
博客园 - 叶小钗
U
Unit 42
博客园_首页
Apple Machine Learning Research
Apple Machine Learning Research
Latest news
Latest news
T
The Exploit Database - CXSecurity.com
博客园 - 三生石上(FineUI控件)
博客园 - 聂微东
T
Threatpost
V
Vulnerabilities – Threatpost
C
Cisco Blogs
Spread Privacy
Spread Privacy
Cisco Talos Blog
Cisco Talos Blog
C
Cyber Attacks, Cyber Crime and Cyber Security
V
Visual Studio Blog
G
GRAHAM CLULEY
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - Franky
G
Google Developers Blog
Know Your Adversary
Know Your Adversary
F
Fortinet All Blogs
H
Hackread – Cybersecurity News, Data Breaches, AI and More
NISL@THU
NISL@THU
N
Netflix TechBlog - Medium
Y
Y Combinator Blog
L
Lohrmann on Cybersecurity
C
CXSECURITY Database RSS Feed - CXSecurity.com
Recent Announcements
Recent Announcements
量子位
S
Schneier on Security
I
Intezer
酷 壳 – CoolShell
酷 壳 – CoolShell
D
Darknet – Hacking Tools, Hacker News & Cyber Security

Datadog | The Monitor blog

Introducing our open source AI-native SAST Instrument and monitor Boomi integration flows with OpenTelemetry and Datadog Not all index scans are equal: How we cut query latency by over 99% Platform engineering metrics: What to measure and what to ignore Integrate Recorded Future threat intelligence with Datadog Cloud SIEM CI/CD security: threat modeling using a MITRE-style threat matrix CI/CD security: How to secure your GitHub ecosystem Ingress NGINX is EOL: A practical guide for migrating to Kubernetes Gateway API Operating agentic AI with Amazon Bedrock AgentCore and Datadog LLM Observability: Lessons from NTT DATA Introducing the Datadog Code Security MCP Capture and analyze custom heatmaps in Session Replay Understand session replays faster with AI summaries and smart chapters Monitor ClickHouse query performance with Datadog Database Monitoring How we designed empathetic alert sounds for on-call engineers Search and act across Datadog to resolve issues faster with Bits Assistant Measure the business impact of every product change with Datadog Experiments Analyzing round trip query latency Configuring JavaScript caches for better performance Introducing Bits AI Dev Agent for Code Security Datadog achieves ISO 42001 certification for responsible AI Monitor Nutanix clusters, hosts, and VMs with Datadog Monitor Juniper Mist in Datadog A new Host Map for modern infrastructure Annotate traces to improve LLM quality with Datadog LLM Observability What’s new in Cloud SIEM: AI-powered investigations, enhanced threat intelligence, and scalable security operations Explore Kubernetes with native OpenTelemetry data Monitor Oracle Fusion Cloud Applications with Datadog Announcing the Datadog Terraform provider v4.0.0 Scaling Kubernetes workloads on custom metrics How to design cloud environments for AI-powered threat analysis Monitor Aruba Central in Datadog How we centralize and remediate risks with Datadog Case Management Accelerate incident response with Datadog and ServiceNow Monitor your application and network load balancer logs Understanding Karpenter architecture for Kubernetes autoscaling Tools for collecting metrics and logs from Karpenter Monitor Karpenter with Datadog What your product data is actually saying Key metrics for monitoring Karpenter Securing Datadog’s platform in the AI age: The role of observability data Four ways engineering teams use the Datadog MCP Server to power AI agents Approaching your observability migration with the right mindset Meet the new Bits AI SRE: Deeper reasoning, twice as fast Key learnings from the 2026 State of DevSecOps study Use plain English to query your multi-cloud infrastructure in Resource Catalog Simplifying troubleshooting across the user journey with Datadog Synthetic Monitoring Protect your OCI resources with Datadog Cloud Security This Month in Datadog - February 2026 Amazon EC2 security: How misconfigured and public AMIs expand your cloud attack surface Enable end-to-end visibility into your Java apps with a single command Measure and improve mobile app startup performance with Datadog RUM Evaluating our AI Guard application to improve quality and control cost Identify untested code across every level of your codebase Make use of guardrail metrics and stop babysitting your releases Monitor Versa Networks SD-WAN performance in Datadog Improve performance and reliability with APM Recommendations Remediate transitive vulnerabilities faster with Datadog Software Composition Analysis Generate audit-ready vulnerability and compliance reports with Datadog Sheets Monitor Fortinet FortiManager performance in Datadog Improve test coverage across codebases with Datadog Code Coverage Move fast, don’t break things: Consistent testing standards at scale Enrich logs with ServiceNow CMDB context before routing to any SIEM or logging tool Monitor Lustre with Datadog Make faster, better product decisions with Datadog Product Analytics Surface and remediate runtime posture issues with Workload Protection Findings Protect agentic AI applications with Datadog AI Guard How to optimize JavaScript code with CSS Trace Google Pub/Sub workloads in Cloud Run with Datadog Detect human names in logs with ML in Sensitive Data Scanner How we cut our NLQ agent debugging time from hours to minutes with LLM Observability Debug PostgreSQL query latency faster with EXPLAIN ANALYZE in Datadog Database Monitoring Datadog acquires Propolis Unify and correlate frontend and backend data with retention filters Scale compliance across global frameworks with Datadog Cloud Security Monitor Arista VeloCloud SD-WAN performance with Datadog Building reliable dashboard agents with Datadog LLM Observability Simplify log collection and aggregation for MSSPs with Datadog Observability Pipelines Mitigation for Node.js denial-of-service vulnerability affecting Datadog APM Automate flaky test fixes with the Bits AI Dev Agent and Test Optimization How we built an AI SRE agent that investigates like a team of engineers Datadog integrations 2025 recap: Observability for AI, security, and hybrid cloud Design effective executive dashboards with Datadog Implement dbt data quality checks with dbt-expectations Bring faster visibility into AWS Lambda functions with remote instrumentation Troubleshoot faster with the GitLab Source Code integration in Datadog How Cambia Health Solutions saved $30,000 monthly with Cloud Cost Management and the Datadog Resource Catalog Normalize any logs for Cloud SIEM with Datadog's OCSF processor Optimizing Datadog at scale: Cost-efficient observability at Zendesk Detect, diagnose, and resolve network issues easily with CNM Network Health Connect engineering errors to user impact in early-stage products Cilium configuration for Kubernetes operations at scale Designing feedback loops for progressive delivery Ship features faster and safer with Datadog Feature Flags Choosing the right OpenTelemetry Collector distribution Route your monitor alerts with Datadog monitor notification rules Automate Cloud SIEM investigations with Bits AI Security Analyst Cloud threat detection: How to identify risky activity across control and data planes Collecting Kafka performance metrics Monitoring Kafka with Datadog Monitoring Kafka performance metrics
Install OpenStack in two commands for dev and test
2016-01-26 · via Datadog | The Monitor blog
Evan Mouzakitis

This article will show you how to get a full OpenStack stack running in just two commands using DevStack. DevStack is not intended to be a general OpenStack installer, but is a great option for dev/test.

Because it was made for development and testing, DevStack takes most of the decision making out of the installation process, presenting you with a default installation environment that Just Works™.

Motivation

Although DevStack does make it easier to get an OpenStack environment up and running, it is not without its pain points. In my case, I needed an environment that I could remotely deploy and tear down daily, using a cloud provider to host my installation. After spending a sizable chunk of time over the course of a few days, I realized I could cut down my redeployment times considerably with a set of scripts that could customize my installation.

With some additional tooling, I was able to build a nearly fully automated solution that has cut deployment times down and ensures a completely reproducible build by other members of my team.

Prerequisites

The DevStack installation target should be based on an Ubuntu or Debian image. If you are deploying to a cloud environment, we have included additional instructions for deploying to either DigitalOcean or AWS as the hosting provider.

Perhaps the fastest way to get a one-off deployment working quickly is to create a droplet (at least 4GB of RAM recommended) from the DigitalOcean web interface and follow the vanilla VM setup steps below. The same steps can be used to host your DevStack deployment on a different platform.

Choose your setup from the following:

No matter where you host your deployment, it is recommended that you read through vanilla VM setup so you have an idea of the changes being made to your system.

Vanilla VM setup

The DevStack documentation strongly suggests using a disposable virtual machine to host the project, as DevStack makes a considerable number of changes to its host system.

Once you download the stack_setup.sh script described below, getting up DevStack can be done in two commands:

./stack_setup.sh

sudo -iu stack bash /usr/local/src/devstack/stack.sh

stack_setup.sh

The stack_setup.sh script prepares the local environment for DevStack installation. You can download the script with wget: wget https://raw.githubusercontent.com/DataDog/the-monitor/master/openstack/devstack/stacksetup.sh

After downloading the script, don’t forget to make it executable with chmod +x stack_setup.sh

Before stack_setup.sh can do anything interesting, it performs some housekeeping: updating apt repositories, and installing git. This step is especially necessary for DigitalOcean users, as the default Ubuntu install does not have git and usually has an outdated package list.

Next, the script clones the Kilo release of DevStack into /usr/local/src/devstack and creates a stack user with the bundled create-stack-user.sh script from the tools directory. Creating a separate user to run DevStack is necessary, as the installation scripts will refuse to run as root.

After creating the new user, the script creates a local.conf file, used to configure your deployment. It sets up and configures OpenStack notifications so you can view OpenStack events immediately, using the popular StackTach tool or a custom listener.

Most importantly, it sets defaults for the admin, database, RabbitMQ, and Horizon passwords, as well as the service token to bootstrap Keystone. The DevStack documentation recommends pre-set passwords to simplify the installation process. If you would like to change the defaults, modify the password options in the stack_setup.sh script. The default password is: devstack.

Finally, the script changes ownership of all files in the devstack directory (and subdirectories) to the stack user.

stack.sh

The final step in deploying DevStack is running the stack.sh script as the stack user. This script handles the actual deployment of DevStack. It is highly recommended that you carefully read the script contents to better understand the changes OpenStack will make to your system. No user interaction should be needed until the script finishes.

AWS deployment

Deploying on AWS requires you to manually create an EC2 instance to host your deployment, as well as open up several ports for OpenStack to use.

Deploy DevStack on AWS - Instance Size choice

The minimum instance size to host DevStack is m4.large. Although smaller instance types could host DevStack, over the course of our tests we found the network performance of smaller instance sizes to be inadequate. We also used the Ubuntu Server 14.04 LTS (HVM), SSD Volume Type image for our test deployment.

To ensure access to the outside world, assign a public IP address to your instance like in the screenshot below:

Deploy DevStack on AWS - Assign Public IP

Last but not least, you must open up access to a number of ports in order for DevStack to successfully install. You could just open up your instance to all internet traffic, but configuring a security group is a good idea if you’d like to restrict outside access to your deployment.

Create a security group with the following ports open for ingress: 22, 80, 443, 3306, 5000, 5672, 5900 - 5999, 6000 - 6002, 6080 - 6082, 8000, 8003, 8080, 8386, 8773 - 8777, 9191, 9292, 9696, 35357. Refer to the OpenStack documentation for more information on OpenStack service ports.

Deploy DevStack on AWS - Configure Port Access

Once launched, open up a terminal on your local machine. Use scp to copy the stacksetup.sh script to your EC2 instance: scp stacksetup.sh ubuntu@<your instance IP>:~. The previous command will upload the setup script to /home/ubuntu/setup_script.sh on your instance.

Next, ssh into your instance and run the script as root:

ssh ubuntu@<your instance IP>

ubuntu@<your instance IP>:~$ sudo ./stack_setup.sh

Once the script executes, you will have a copy of the DevStack project in /usr/local/src/devstack and a new stack user.

Then, you just need to execute stack.sh as the stack user.

sudo -iu stack bash /usr/local/src/devstack/stack.sh

The script should take ~20 minutes to execute. When it is finished, continue on to Success to get started with your new deployment.

DigitalOcean deployment with Tugboat

If you have a DigitalOcean droplet running, you can simply run the vanilla VM setup steps to install OpenStack.

If you want to automate the entire OpenStack setup, including provisioning machines, you can do that on DigitalOcean using Tugboat. If you plan on doing a lot of OpenStack testing, chances are you’ll break some things along the way. With Tugboat, you can quickly and easily deploy and tear down your stack, so you have a fresh deployment to hack on daily. The next section of this article explains how to use Tugboat to create and setup a droplet running DevStack.

Tugboat configuration

Tugboat is a handy package that allows you to manage your DigitalOcean account from the command line. We will take advantage of its powerful features to create an appropriately sized droplet to host our DevStack deployment.

Tugboat requires Ruby 1.9 or higher. Check for a compatible version with ruby -v. Once you’ve upgraded Ruby or verified your version, installation is a single command: gem install tugboat.

Tugboat needs an authentication token from DigitalOcean—you can grab yours here. You can only view your token once upon creation, so make sure you store it somewhere as you will need it in the next step.

With authentication token in hand, run tugboat authorize. You should see a series of prompts, reproduced below. You need only to enter your access token and a path to an SSH key; the defaults should suffice for the rest.

user@testing:~$ tugboat authorize

Note: You can get your Access Token from https://cloud.digitalocean.com/settings/tokens/new

Enter your access token: <your access token>

Enter your SSH key path (optional, defaults to ~/.ssh/id_rsa) :

Enter your SSH user (optional, defaults to root):

Enter your SSH port number (optional, defaults to 22):

To retrieve region, image, size and key ID's, you can use the corresponding tugboat command, such as `tugboat images`.

Defaults can be changed at any time in your ~/.tugboat configuration file.

Enter your default region (optional, defaults to nyc1):

Enter your default image ID or image slug (optional, defaults to ubuntu-14-04-x64):

Enter your default size (optional, defaults to 512mb)):

Enter your default ssh key IDs (optional, defaults to none, comma separated string):

Enter your default for private networking (optional, defaults to false):

Enter your default for enabling backups (optional, defaults to false):

Authentication with DigitalOcean was successful!

If you see “Authentication with DigitalOcean was successful!”, you’re good to go.

After authenticating, make sure to set a default SSH key. You can get a list of your SSH key IDs with tugboat keys.

Name: tutum-70159d08-bfe8-44de-b0a1-4ce0d2dd9682, (id: 1529470), fingerprint: c4:b0:f2:b0:a7:9f:89:d0:c5:ae:b5:5c:f3:de:a0:69

Name: DO-webserver, (id: 1532126), fingerprint: 37:75:95:7d:93:4f:e0:fd:01:4a:ba:e4:2e:be:6d:c7

For example, if you wanted to use the DO-webserver key listed in the output above, open up tugboat’s configuration file at ~/.tugboat and change the value of ssh_key to 1532126.

deploy_droplet.py

deploy_droplet.py is a Python script that creates an appropriately sized droplet on DigitalOcean to host DevStack. You need only to provide a name for your droplet, which you can supply either as a command line parameter or as input at the prompt.

You can download the script with the following command: wget https://raw.githubusercontent.com/DataDog/the-monitor/master/openstack/devstack/deploy_droplet.py

Once downloaded, make the script executable and then run deploy_droplet.py

chmod +x deploy_droplet.py

./deploy_droplet.py <your_droplet_name>

which should produce output resembling the following:

$ ./deploy_droplet.py devstack-test

Queueing creation of droplet 'devstack-test'...Droplet created!

Droplet fuzzy name provided. Finding droplet ID...done, 9591284 (devstack-test)

Waiting for droplet to become active................done (30s)

IP: 107.170.165.252

Run the following (in order):

ssh root@107.170.165.252 'bash -s' < stack_setup.sh

ssh root@107.170.165.252

sudo -iu stack bash /usr/local/src/devstack/stack.sh

As you can see from the above output, the script creates the droplet, returns its IP address, and lists a series of commands to execute in order on the newly created instance. Simply copy-paste the commands to set up OpenStack. If you’d like more information on the work performed in each step of the script, jump to vanilla VM setup. Otherwise, skip ahead to start using your new deployment.

Success

Wherever you chose to deploy DevStack, once setup is complete you should be greeted with output like the following:

Horizon is now available at http://107.170.165.252/

Keystone is serving at http://107.170.165.252:5000/

The default users are: admin and demo

sThe password: devstack

To access statistics about your deployment, including number of instances and quota usage, navigate to the Horizon address listed in the output.

Log in as the admin user with password: devstack
Deploy DevStack Horizon Dash Screen
Log in as the admin user with password: devstack

Conclusion

On average, you should expect the following approximate execution times for the various steps listed in this post:

-deploy_stack.py: ~20-60 seconds

-stack_setup.sh: ~1 minute

-stack.sh: ~16-26 minutes

-Approximate total execution time: < 30 minutes

Of course, your actual installation time will vary depending on your network speed.

If you’ve been following along on your own machine, you should now have a DevStack deployment ready for use. To learn how to monitor an OpenStack deployment, check out our three-part series.