如何从C++项目向本地Docker容器传递参数并获取应用输出？

Absolutely! There are several solid, practical ways to pass parameters from your C++ project to local Docker containers and fetch output from specific apps running inside them. Let’s break down the most reliable approaches, with code examples to get you started:

1. Use Docker CLI + C++ Process Invocation #

This is the simplest approach if you already have Docker CLI installed on your system. You can execute Docker commands (like docker exec) directly from your C++ code using process invocation utilities, then capture the output.

Here’s a quick example using popen() to run a command inside a container and read its output:

#include <iostream>
#include <cstdio>
#include <string>

int main() {
    // Configure your target container and app details
    const std::string container_name = "my-target-container";
    const std::string app_path = "/usr/local/bin/my-custom-app";
    const std::string input_param = "my-test-parameter";

    // Build the full Docker exec command
    std::string cmd = "docker exec " + container_name + " " + app_path + " " + input_param;

    // Execute the command and capture stdout
    FILE* pipe = popen(cmd.c_str(), "r");
    if (!pipe) {
        std::cerr << "Error: Failed to execute Docker command!" << std::endl;
        return EXIT_FAILURE;
    }

    char buffer[256];
    std::string app_output;
    while (fgets(buffer, sizeof(buffer), pipe) != nullptr) {
        app_output += buffer;
    }
    pclose(pipe);

    // Print the captured output
    std::cout << "Output from container app:\n" << app_output << std::endl;
    return EXIT_SUCCESS;
}

Pros: No extra dependencies, quick to implement, leverages existing Docker CLI functionality.
Cons: Relies on Docker CLI being available on the system; error handling is less granular compared to SDKs.

2. Use a Docker C++ SDK #

For more native integration and better control, use a C++ SDK that interacts directly with the Docker daemon. Libraries like docker-cpp-sdk or libdocker let you manage containers, execute commands, and capture output without spawning external processes.

Here’s a simplified example using docker-cpp-sdk:

#include <docker/docker.h>
#include <iostream>

int main() {
    try {
        // Connect to the local Docker daemon (defaults to unix:///var/run/docker.sock)
        docker::Client docker_client;

        // Define options for the exec command
        docker::ExecCreateOptions exec_opts;
        exec_opts.cmd = {"/usr/local/bin/my-custom-app", "my-test-parameter"};
        exec_opts.attach_stdout = true;
        exec_opts.attach_stderr = true;

        // Create an exec instance for your target container
        auto exec_instance = docker_client.execCreate("my-target-container", exec_opts);

        // Start the exec and capture output
        docker::ExecStartOptions start_opts;
        auto exec_output = docker_client.execStart(exec_instance.id, start_opts);

        // Print results
        std::cout << "Stdout:\n" << exec_output.stdout << "\n\nStderr:\n" << exec_output.stderr << std::endl;
    } catch (const docker::DockerException& e) {
        std::cerr << "Docker SDK Error: " << e.what() << std::endl;
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

Pros: Native C++ integration, precise error handling, no reliance on external CLI processes.
Cons: Requires installing and configuring a third-party library; steeper learning curve for advanced features.

3. Network-Based Communication (HTTP/REST or gRPC) #

If the app inside your container exposes a network interface (like an HTTP API or gRPC service), you can directly send parameters from your C++ project over the network and fetch the response. This is ideal for service-oriented architectures.

Example using the C++ REST SDK (cpprestsdk) to send an HTTP request to a containerized app:

#include <cpprest/http_client.h>
#include <cpprest/filestream.h>

using namespace web;
using namespace web::http;
using namespace web::http::client;

int main() {
    try {
        // Target the container's exposed port (mapped to localhost)
        http_client client(U("http://localhost:8080"));

        // Build a request with your parameter (e.g., via query string)
        uri_builder builder(U("/run-app"));
        builder.append_query(U("input"), U("my-test-parameter"));

        // Send GET request and wait for response
        http_response response = client.request(methods::GET, builder.to_string()).get();

        if (response.status_code() == status_codes::OK) {
            std::string output = response.extract_string().get();
            std::cout << "App Output:\n" << output << std::endl;
        } else {
            std::cerr << "Request failed with status code: " << response.status_code() << std::endl;
        }
    } catch (const std::exception& e) {
        std::cerr << "Network Error: " << e.what() << std::endl;
        return EXIT_FAILURE;
    }
    return EXIT_SUCCESS;
}

Pros: Loose coupling between your C++ project and containers; works well for distributed setups.
Cons: Requires the containerized app to support network communication; needs port mapping configuration in Docker.

4. Shared Volumes for File-Based Interaction #

If you’re working with large datasets or file-based input/output, use Docker shared volumes to exchange data between your C++ project and the container. Your C++ code writes parameters to a shared directory, the containerized app reads them, then writes output back to the same directory for your C++ project to consume.

Example workflow:

1. Create a shared volume or bind mount: docker run -v /local/shared/path:/container/shared/path my-target-container
2. C++ code writes parameters to the shared directory:

#include <fstream>
#include <iostream>
#include <string>

int main() {
    const std::string shared_dir = "/local/shared/path";
    const std::string param_file = shared_dir + "/input.txt";
    const std::string output_file = shared_dir + "/output.txt";

    // Write parameter to shared file
    std::ofstream out_param(param_file);
    if (!out_param.is_open()) {
        std::cerr << "Error: Could not write parameter file!" << std::endl;
        return EXIT_FAILURE;
    }
    out_param << "my-test-parameter";
    out_param.close();

    // Trigger the app in the container (using docker exec)
    system("docker exec my-target-container /usr/local/bin/my-custom-app /container/shared/path/input.txt /container/shared/path/output.txt");

    // Read output from shared file
    std::ifstream in_output(output_file);
    if (!in_output.is_open()) {
        std::cerr << "Error: Could not read output file!" << std::endl;
        return EXIT_FAILURE;
    }
    std::string app_output((std::istreambuf_iterator<char>(in_output)), std::istreambuf_iterator<char>());
    std::cout << "App Output:\n" << app_output << std::endl;
    in_output.close();

    return EXIT_SUCCESS;
}

Pros: Ideal for large files/batch data; no network overhead.
Cons: Requires handling file synchronization (e.g., waiting for the app to finish writing output); less suitable for real-time interactions.

Which Approach Should You Choose? #

• Go with Docker CLI + Process Invocation for quick, simple use cases.
• Use a Docker C++ SDK if you need fine-grained control and native integration.
• Opt for Network Communication if your containerized app is a service.
• Pick Shared Volumes for file-heavy workflows.

内容的提问来源于stack exchange，提问作者HilmiK