Lab Environment Management: Restart, Reset, Connectivity, and Support Guide
Managing a hands‑on DevSecOps lab should be seamless, but occasional hiccups—like a stalled VM, lost configuration, or network blockage—can interrupt your learning flow. This guide walks you through the essential actions for restarting, resetting, and troubleshooting connectivity in the Practical DevSecOps labs, plus how to get help when you need it.
Table of Contents
Restarting Your Lab Machine
When a VM becomes unresponsive or you need to apply a system update, a simple restart can restore normal operation.
How to Restart
-
Locate the Restart button on the right‑hand side of the lab console.
-
Click Restart.
-
If you are using one of the GitLab machines, the platform automatically restarts the companion GitLab instances to keep the environment in sync.
Pro tip: Give the VM 60–90 seconds after the restart command before re‑connecting. This ensures all services have fully initialized.
Resetting the Lab Environment
A reset returns the entire lab to its original, clean state—useful when you want to start over or when configuration changes have caused errors. Warning: Resetting erases all data on the machine, so back up any important files first.
Step‑by‑Step Reset Procedure
-
Refresh the exercise page in your browser.
-
Below the Start the exercise button, click Reset my environment.
-
A confirmation pop‑up appears. Read the warning, then click Yes, Reset my environment.
-
The provisioning process begins; you’ll see a progress indicator.
What Gets Reset?
-
All user‑created files and directories
-
Installed packages and custom configurations
-
Database contents and Docker containers
Example Scenario
You’ve been experimenting with a custom CI/CD pipeline that broke the GitLab runner. Rather than debugging each step, you click Reset my environment to revert to the pristine lab state and try a different approach.
Connectivity Checklist
If you cannot reach the labs, follow this systematic troubleshooting flow.
-
Verify Internet Stability – Run a speed test or open a few unrelated websites.
-
Refresh & Reset – Reload the lab page, then click Reset my environment before launching the lab again.
-
Disable Interfering Software – Turn off any ad‑blockers, VPNs, or corporate firewalls that might block WebSocket traffic.
-
Use Incognito/Private Mode – This bypasses cached data and extensions that could interfere.
-
Switch Browsers – Google Chrome is the recommended browser for optimal WebSocket support.
-
Change Network – Connect via a different Wi‑Fi network, mobile hotspot, or Ethernet cable.
-
Try Another Device – If possible, launch the lab from a different laptop or desktop.
If none of the above resolves the issue, move on to the Support section.
Whitelisting Required Domains & Ports
Corporate firewalls often block the domains needed for the lab platform. Add the following entries to your allow‑list:
| Category | Domains / URLs | Notes |
|---|---|---|
| Core Platform | *.practical-devsecops.training |
Main lab UI and API |
| Chat & Collaboration | chat.practical-devsecops.com |
Chatbot chat |
| Lab Sub‑domains | *.lab.practical-devsecops.training |
Individual lab instances |
| Media Content | vimeo.com |
Embedded tutorial videos |
| Portal | https://chnl.portal.practical-devsecops.training |
Course portal & resources |
Network Ports
-
80 (HTTP) – Required for initial redirects.
-
443 (HTTPS) – Secure traffic for all UI, API, and WebSocket connections.
Protocols
-
HTTP/HTTPS – Standard web traffic.
-
WebSocket (wss) – Real‑time communication between your browser and the lab containers.
Ensuring these domains and ports are open eliminates the most common connectivity roadblocks.
Getting Support
Technical roadblocks happen, and our support team is ready to help. Choose the channel that best fits your urgency:
-
Chatbot Chat – Real‑time assistance and you can request a real agent for urgent issue.
-
Email – Send detailed queries (including screenshots and error logs) to registrations@practical-devsecops.com.
When contacting support, include:
-
Your user ID or registration email.
-
A brief description of the problem.
-
Steps you’ve already tried (e.g., browser switch, network change).
-
Any error messages or screenshots.
Quick Tips & FAQs
Common Questions
-
Q: Will restarting a GitLab machine affect my other lab VMs?
A: No. Restarting a single GitLab VM triggers an automatic restart of the other GitLab nodes only to keep the cluster synchronized. Your other independent labs remain untouched. -
Q: How long does a reset take?
A: Typically 2–4 minutes, depending on the lab size and current platform load. -
Q: Can I export my work before resetting?
A: Yes. Usescp,git push, or download files via the web UI before you click Reset my environment.
Handy Tips
-
Bookmark the support chat for one‑click access during a lab session.
-
Take periodic snapshots of your work (e.g., push to a personal Git repo) to avoid data loss.
-
Use Chrome’s “Clear browsing data” (cookies & cache) if you notice stale UI elements after a reset.
Stay Productive
By mastering these restart, reset, and connectivity steps, you’ll spend more time building secure pipelines and less time troubleshooting the lab infrastructure. Keep this guide handy, and you’ll navigate any technical snag with confidence. Happy learning!