Huawei Cloud Credit Voucher Top-up Deploying Web Applications on Huawei Cloud International

Huawei Cloud / 2026-05-07 10:11:49

Deploying a web application on any cloud can feel like assembling IKEA furniture while someone keeps changing the picture on the box. Huawei Cloud International is no exception—except it comes with a slightly different set of knobs, buttons, and menus that make you wonder if you accidentally joined a secret society. The good news: once you understand the building blocks, deploying becomes far less mysterious and far more repeatable. In this article, we’ll walk through a clear, practical approach to getting your web app running, accessible, and stable in the real world.

Before You Start: Know What You’re Shipping

Before clicking anything, answer these questions. Not because a cloud consultant demands it, but because your future self will thank you when you’re troubleshooting at 2 a.m.

What kind of web app is it? A traditional monolith (e.g., Django/Express/.NET) or something containerized (e.g., Docker-based)? Or maybe a frontend + API setup?
What runtime do you need? Node.js? Java? Python? .NET? Static files only? Web servers? Background workers?
How should it scale? Horizontal scaling (more instances) or vertical scaling (bigger instances)?
Do you need databases? If yes, what type and how will you secure access?
How “internet-facing” is it? Public site, internal app, or hybrid?

If you can describe your app in one sentence and list the dependencies (compute, storage, database, secrets, domain name), you’re ready to deploy. If you can’t, deploy anyway, but expect extra chaos. That’s the cloud’s version of a surprise party.

Understand the Huawei Cloud International Building Blocks

Cloud platforms are basically fancy orchestration systems for the same old ingredients: compute, networking, storage, and a way to expose your app to users. Huawei Cloud International provides many options depending on your style.

Here are the common categories you’ll encounter:

Compute: Virtual machines for classic deployments, or container solutions for modern deployments.
Networking: Virtual Private Cloud (VPC), subnets, security groups, routing, and load balancing.
Load balancing: To distribute traffic and provide health checks and scaling-friendly behavior.
Storage: Object storage for static assets or file storage for app needs.
Databases: Managed databases (if you don’t want to run one yourself).
DNS and Domain services: Connect your domain name to the load balancer or public endpoint.
SSL/TLS: Certificates for HTTPS so users don’t see browser warnings like “Your site is having a problem.”
Observability: Logging, metrics, monitoring, and sometimes tracing for debugging.

The trick is choosing the right combination for your use case. Let’s do that with two common deployment patterns: (1) container-based deployments and (2) VM-based deployments. You can mix and match, but starting simple is the fastest way to success.

Pick a Deployment Approach

There are multiple ways to deploy a web application on Huawei Cloud International. Here’s how to decide without reading a hundred forum posts and questioning your life choices.

Option A: Container-based Deployment (Modern and Repeatable)

If your app is already containerized (or you can easily containerize it), using a container platform is often the cleanest route. Containers make it easier to keep environments consistent from development to production. You’ll also generally find scaling and rolling updates more manageable.

Typical workflow:

Build a Docker image
Push it to a container registry
Deploy it using a container service
Set up networking, load balancing, and HTTPS

Option B: VM-based Deployment (Straightforward, Classic)

If you prefer direct control, or your app is not container-friendly, deploying onto virtual machines can be a good choice. You’ll install dependencies, configure the web server (like Nginx, Apache, or a reverse proxy), deploy the application, and set up auto-scaling policies if available.

Typical workflow:

Create an instance (VM) with the right OS and size
Install runtime and dependencies
Deploy the app
Configure a reverse proxy
Put a load balancer in front

Either approach works. Containers are usually more “DevOps-friendly,” while VMs can be simpler for immediate results. Choose the one that matches your team’s comfort level and your timeline.

Set Up Networking: VPC, Subnets, and Security

Huawei Cloud Credit Voucher Top-up Networking is where your deployment dreams either become reality or get stuck behind a locked door with a “No Entry” sign.

At a high level, you’ll need:

Huawei Cloud Credit Voucher Top-up A VPC to isolate your network resources.
A subnet inside the VPC where compute resources live.
Security rules to allow inbound traffic to your app only on necessary ports.
Huawei Cloud Credit Voucher Top-up Connectivity for outgoing traffic (e.g., updates, external APIs).

When configuring security, aim for least privilege:

If your app listens on port 80 internally, only allow load balancer to reach it.
If you use HTTPS at the load balancer, internal traffic might still be HTTP between the load balancer and your instances. That’s okay if it’s properly controlled.
Huawei Cloud Credit Voucher Top-up Don’t open SSH (port 22) to the world. Restrict it to your IP or VPN.

Also plan for health checks. Load balancers typically need a path (like /health) that returns a simple success response.

Expose Your Application: Load Balancers and Listener Setup

Users should never have to know how your application is deployed behind the curtain. They just want a URL that works. A load balancer helps by distributing requests to healthy instances and handling traffic spikes.

Load balancer configuration usually includes:

Listeners: Port 80 for HTTP and port 443 for HTTPS.
Target groups or backend pools: Your compute instances or container services.
Huawei Cloud Credit Voucher Top-up Health checks: HTTP checks to verify instances are alive.
Session behavior: Usually stateless; if you need sticky sessions, configure accordingly.

One useful practice: create a lightweight endpoint such as /health or /status that performs only minimal checks (for example, returning 200 OK if the app process is running). If your health check tries to connect to every dependency (database, cache, third-party services) and one of them is slow, your load balancer might “helpfully” remove healthy instances. It’s like a lifeguard deciding your pool noodle isn’t floating well enough.

SSL/TLS: Make It HTTPS or It’s Just Polite HTTP

Huawei Cloud Credit Voucher Top-up If you want browsers to trust your site, you need HTTPS. That means configuring SSL/TLS with a certificate. Huawei Cloud International typically supports certificate management workflows where you can upload or reference certificates and attach them to the load balancer listener.

Best practices for SSL/TLS:

Use modern TLS versions (and avoid overly old settings).
Make HTTP redirect to HTTPS if possible.
Set up correct domain coverage for certificate issuance (e.g., app.example.com).

If you already use Let’s Encrypt, you might have a workflow for certificate renewal. If you’re using managed certificates, follow the renewal strategy your provider expects. Expired certificates are the slowest villain in the story.

Domain and DNS: Point Your Name to the Cloud

Next, connect your domain to your deployment endpoint. Usually this means:

Creating DNS records (A or CNAME) that point to your load balancer’s public address or hostname.
Ensuring DNS propagation and verifying routing.

Common pattern:

Huawei Cloud Credit Voucher Top-up example.com points to load balancer (often via A records)
www.example.com points to the same place (often via CNAME)

Don’t forget that SSL certificates depend on domain names. If you attach a certificate for app.example.com but your DNS points example.com to a different endpoint, you’ll get a mismatch and your browser will act like it just saw a ghost.

Huawei Cloud Credit Voucher Top-up Deploy the Application: Container Path (Step-by-Step)

Let’s walk through a practical container-based deployment pattern. Exact service names vary by account and region, but the logical steps are consistent.

Step 1: Build a Docker Image

Create a Dockerfile that copies your application code, installs dependencies, and starts your app. For example, you’ll want:

Proper working directory
Dependency installation
Non-root user if feasible
Exposed port
A CMD or ENTRYPOINT to start the server

Also ensure your app reads configuration from environment variables. Hardcoding production secrets or URLs is like seasoning a meal with molten lava—you’ll regret it later.

Step 2: Push the Image to a Registry

Use a container registry service to store your image. Tag images with version identifiers (like 1.2.3 or a commit hash). Example tags:

myapp:1.0.0
myapp:latest (use carefully)
myapp:git-

Shipping a new image shouldn’t depend on “latest” being exactly the image you intended. If you must use latest, make sure you know what you’re doing.

Step 3: Create a Deployment Configuration

Define how containers should run:

Image reference from the registry
Container port (the port your app listens on inside the container)
Environment variables (non-secret config and secret references)
Resource settings (CPU/memory requests and limits)
Health checks (liveness/readiness) if supported

If your app requires a writable directory (for logs or temporary files), ensure the container has appropriate filesystem access. Containers are ephemeral by design—treat them like goldfish. They remember nothing after restart.

Step 4: Integrate with Load Balancer

Connect your container service or instances to the load balancer backend. Ensure:

The backend port matches your app’s listening port.
The load balancer health check path exists and returns expected status codes.
Time-outs are reasonable for your app’s startup behavior.

Tip: if your app takes 30-60 seconds to boot (common with migrations or warm caches), adjust health check grace periods or initial delays so the load balancer doesn’t declare it dead before it’s alive.

Step 5: Configure Environment Variables and Secrets

Use secret storage mechanisms if available. Your app should receive secrets like database credentials, API keys, and signing tokens through secure variables.

Common approach:

Set database host, username, and password via environment variables
Set application settings (e.g., allowed hosts, log level, external service URLs)
Provide a key for JWT signing or session encryption if needed

Avoid logging secrets. If you print environment variables during startup “for debugging,” consider it a public announcement to anyone with access to logs: “Hello, thieves.”

Step 6: Validate with Real Requests

Once deployed, test:

HTTP and HTTPS responses
Static assets loading (if any)
API endpoints returning correct data
Authentication flows (if your app uses login)
Error pages (404/500) to confirm your routes and error handlers

Also check the browser console and network tab. Many “it doesn’t work” issues are actually “the frontend can’t reach the API because you misconfigured CORS or the API base URL.” The cloud didn’t break your code. Your code is just doing exactly what you told it to do. In a cruelly literal way.

Deploy the Application: VM Path (Step-by-Step)

Now let’s do the VM approach. Think of this as hosting your own mini computer factory, except the cloud handles the building and delivery. You handle the software inside the box.

Step 1: Provision a VM

Choose:

An OS image compatible with your runtime
Instance size based on expected traffic
Network placement in your VPC and subnet

During setup, set firewall/security group rules to allow only the load balancer to reach your app port. Don’t open unnecessary ports.

Step 2: Install Runtime and Web Server

Install your runtime (Node, Java, Python, .NET) and a reverse proxy web server such as Nginx. Common tasks:

Install packages and dependencies
Set up Nginx configuration to proxy requests to your app
Configure logs for debugging

If you’re using Nginx, you’ll likely configure something like:

server block for your domain or default server
proxy_pass to your app’s local port
headers forwarding (Host, X-Forwarded-For)

Don’t ignore forwarding headers. Without them, your app may generate incorrect URLs, fail authentication callbacks, or log mystery client IP addresses like “127.0.0.1” (which is a fun detective story, but not the one you want).

Step 3: Deploy the Application Files or Artifact

Deploy your app code or build artifact:

Use a repository checkout
Or download a build package from your CI/CD pipeline
Or deploy via a versioned release directory

Make sure you can restart the app cleanly. Using process managers (like systemd, pm2, supervisor) helps.

Step 4: Configure HTTPS Strategy

Typically, SSL termination happens at the load balancer. Your VM can listen on HTTP internally, and Nginx can proxy to your app. That keeps certificate management centralized.

If you terminate SSL on the VM, you’ll need certificate installation there as well. Doing it everywhere is like owning 12 umbrellas because it might rain in 12 different ways. It can work, but it’s not elegant.

Huawei Cloud Credit Voucher Top-up Step 5: Add Health Checks and Startup Behavior

Create a health endpoint (or use a basic HTTP check). Ensure your app returns 200 OK quickly after startup, or configure the load balancer to allow time for initialization.

For VM setups, also verify you can restart instances without losing your configuration. Ideally, automate provisioning using scripts or infrastructure-as-code tools.

Databases and Persistent Storage: Keep Your Data Calm

Most web apps eventually hit a database, even if they pretend they don’t. Choose managed database services if you want fewer operational headaches. If you do run databases yourself, plan for backups, monitoring, and replication.

Key considerations:

Network access: Only allow your app instances to connect to the database. Don’t expose DB ports publicly.
Credentials: Use secure secret storage and rotate credentials when needed.
Backups: Ensure backups are enabled and test restores.
Migrations: Run schema migrations in a controlled way before or during deployment.

For stateful file uploads (like user avatars), object storage is often a good choice. Store files in a bucket, then serve them via signed URLs or a CDN. Your app then stays stateless, which makes scaling far easier.

Static Assets and Performance: Don’t Make Users Wait Forever

Performance is part of deployment. If your app serves static files slowly, users will think the app is broken even when the backend is perfectly healthy. Common improvements:

Put static assets (CSS/JS/images) in object storage
Use a CDN if available to reduce latency
Set cache-control headers appropriately
Minify and compress assets in your build pipeline

In many deployments, the load balancer handles dynamic requests, while static content is served from storage. This separation helps keep traffic predictable and improves overall response times.

Logging, Monitoring, and Metrics: Debugging Without Tears

If something breaks, you want to know quickly. Cloud logging and monitoring help you spot issues like:

High error rates (HTTP 500 responses)
App startup failures
Database connection errors
Time-outs and slow responses
Resource exhaustion (CPU/memory limits hit)

Set up:

Application logs: structured logs if possible (JSON helps)
Web server logs: access logs for request/response patterns
Health metrics: request counts, latency, error codes

Then practice “reading logs like a detective.” Start with the time of failure, identify the endpoint involved, and compare with deployment timestamps. Most incidents are boring: someone changed an environment variable, and the app is now connecting to the wrong database host. The cloud didn’t betray you; it merely obeyed.

Scaling and High Availability: Planning for Success

Once your app runs, you’ll want it to survive traffic growth and failures. Scaling strategies typically include:

Horizontal scaling: run multiple instances behind a load balancer.
Autoscaling: add instances based on CPU, memory, or request metrics.
Multi-zone or multi-instance redundancy: reduce single points of failure.

High availability usually means:

Your load balancer distributes across multiple backend targets.
Your application is stateless or uses shared storage correctly.
Your database architecture supports resilience (replication, failover, backups).

Remember: “scaling” is not just adding more servers. If your app stores session state in memory on one instance, scaling to two instances might break logins unless you use shared session storage. Stateless design makes scaling much less annoying.

CI/CD: Make Deployments Less Painful

Manual deployments are like walking everywhere when you could take the bus. Sometimes it’s fine. But eventually you’ll crave consistency and speed.

A solid CI/CD pipeline usually includes:

Build and test steps
Container image build (if applicable)
Image push to registry
Deployment to a staging environment
Automated checks (health endpoints, smoke tests)
Production deployment (often using manual approval)

For VM-based deployments, CI/CD might upload artifacts and run remote commands. For container deployments, CI/CD updates the running service to a new image tag.

Regardless of approach, adopt versioning and rollback. You don’t want to “hope” the new version works. You want to deploy with confidence and rollback quickly if something goes sideways.

Troubleshooting Guide: The Most Common Deployment Faceplants

Here are classic issues you’ll encounter when deploying web apps. If you see one of these, don’t panic. Panic is just wasted CPU cycles.

Problem: Load Balancer Health Checks Fail

Symptoms:

Backend targets show as unhealthy
Users get 502/503 errors

Common causes:

Health check path doesn’t exist or returns non-200
App listens on a different port than expected
Security rules block load balancer to backend port
App takes too long to start

Fix strategy:

Verify health endpoint returns 200 from within the VPC
Confirm backend port mapping
Huawei Cloud Credit Voucher Top-up Adjust health check grace period / timeouts
Check security group inbound rules

Problem: HTTPS Works, But App Loads Halfway

Symptoms:

Backend API returns data, but frontend fails
Console shows CORS errors
Assets load but API calls don’t

Common causes:

Frontend API base URL points to localhost or wrong domain
CORS configuration doesn’t include your production domain
Mixed content (HTTP requests from an HTTPS page)

Fix strategy:

Set environment variables for production correctly
Update CORS allowed origins
Ensure API calls use HTTPS

Problem: App Returns 500 Internal Server Error

Symptoms:

Users see server errors
Logs show exceptions or missing configuration

Common causes:

Missing environment variables (database password not set)
Database connection refused due to network or firewall
Application code expects a different file path or secret format
Runtime mismatch (wrong Node/Python/Java version)

Fix strategy:

Check application logs around the request time
Confirm secrets and environment variables
Validate database connectivity from the app instance/container
Confirm runtime versions and dependencies

Problem: Works in Staging, Breaks in Production

This is the cloud’s favorite hobby. “Staging” is usually a cheerful, well-behaved twin. “Production” is the twin that learned to drive and now does burnouts.

Common causes:

Different environment variables between staging and production
Different scale or load causing race conditions
Missing database migrations
Different external service endpoints or credentials
More strict security or different network rules

Fix strategy:

Compare configuration and deployment artifacts
Run smoke tests and endpoint checks in production
Check database schema version
Confirm dependency versions

Security Checklist: Don’t Hand Out Keys to Strangers

Security is not a “later” task. It’s an “oops we already got hacked” task, if you ignore it. Here’s a practical checklist for web apps on Huawei Cloud International:

Lock down inbound traffic: Only allow the load balancer to reach backend ports.
Restrict SSH: Use IP allowlists or avoid public SSH entirely.
Use HTTPS everywhere: Redirect HTTP to HTTPS.
Harden instances: Keep OS updated, disable unnecessary services.
Use least-privilege IAM: Only grant the permissions each component needs.
Protect secrets: Use secure secret storage, rotate credentials periodically.
Validate inputs: Basic app security still matters in the cloud.

Also consider backups for databases and storage lifecycles for objects you might need later. If you delete everything “because it’s temporary,” at least label it as temporary in a way future-you can understand.

Cost Considerations: Deploy Without Summoning the Budget Kraken

Cloud costs can creep up like a cat knocking things off the table. Some costs are expected, some are surprising. To manage costs:

Right-size compute: Start with a reasonable instance size and adjust after observing usage.
Use autoscaling: Let the platform add capacity when needed.
Cache static assets: Reduce dynamic load.
Plan load balancer behavior: Ensure you’re not sending unnecessary traffic through expensive components.
Review logs and retention: Excess logging can add cost and noise.

Most teams find the biggest savings by right-sizing and reducing overprovisioning rather than trying to squeeze pennies out of every request.

A Practical “From Zero to Deployed” Roadmap

If you want a straightforward order of operations, use this roadmap:

Step 1: Prepare your app: containerize it (optional), ensure health endpoint exists, externalize config.
Step 2: Set up VPC networking: subnets, security rules, and routing.
Step 3: Provision compute resources (VMs or container service).
Step 4: Set up load balancer: listener, backend targets, health checks.
Step 5: Configure SSL/TLS and attach certificates.
Step 6: Point DNS records to load balancer.
Step 7: Deploy application and set environment variables/secrets.
Step 8: Run smoke tests and verify end-to-end functionality.
Step 9: Enable monitoring/logging and confirm alerts work (at least in theory).
Huawei Cloud Credit Voucher Top-up Step 10: Configure scaling policies and plan rollback.

That list is your “don’t overthink it” map. Overthinking is great for hobbies. Deployment is great when it’s boring.

Conclusion: Deploying on Huawei Cloud International, Without the Drama

Deploying web applications on Huawei Cloud International follows the same fundamental principles as any serious cloud deployment: get your networking right, expose your app securely through a load balancer, enable HTTPS, connect your domain via DNS, and ensure health checks and observability are in place. Whether you choose containers for flexibility or virtual machines for direct control, you’ll be successful if you treat configuration, secrets, and deployment automation as first-class citizens.

So go ahead: take the leap from “it works locally” to “it works globally.” And if something breaks, remember the cloud isn’t your enemy. It’s just a very fast, very literal machine that will always do exactly what you configured—sometimes with the enthusiasm of a toddler pressing every button at once.