Docker Container Management

A comprehensive solution for managing Docker containers on Linux systems, including safe shutdown, startup, and monitoring capabilities.

Features

• Safely shuts down Docker containers
• Handles graceful termination of processes
• Supports custom shutdown scripts
• Automated changelog generation
• Comprehensive documentation

Features

• Safe shutdown of Docker containers with proper cleanup
• Automatic container startup on system boot
• Detailed logging of all operations
• Error handling and recovery
• Container status monitoring
• Performance optimization

Prerequisites

• Linux operating system
• Docker installed and running
• Bash shell (version 4.0+)
• Root or sudo privileges

Installation

1. Clone the repository:

git clone https://github.com/PeterVinter/Manage_linux_docker_containers.git
cd Manage_linux_docker_containers

2. Make the scripts executable:

chmod +x *.sh

Usage

Starting Containers

./startup_docker_container.sh

Shutting Down Containers

./docker_safe_shutdown.sh

Configuration

The scripts can be configured by modifying the following variables:

• TIMEOUT: Maximum time to wait for container shutdown
• LOG_FILE: Location of log files
• CONTAINER_LIST: List of containers to manage

Logging

Logs are stored in:

• startup_logs.txt: Container startup logs
• shutdowns_logs.txt: Container shutdown logs
• shutdowned.txt: Status of shutdown containers

Development

Branch Structure

This repository follows a simplified GitFlow workflow with two main branches:

• main: The stable branch containing production-ready code

  • All releases are tagged from this branch
  • Protected branch requiring PR reviews
  • Must pass all CI checks before merging

• develop: The development branch where features are integrated

  • All feature branches merge here first
  • Contains latest development changes
  • Must pass CI checks before merging

Working with Branches

1. Feature Development

   git checkout develop
   git checkout -b feature/your-feature
   # Make your changes
   git push origin feature/your-feature
   # Create PR to develop

2. Bug Fixes

   git checkout develop
   git checkout -b fix/bug-description
   # Fix the bug
   git push origin fix/bug-description
   # Create PR to develop

3. Release Process

   • Features are merged into develop
   • When ready for release, develop is merged into main
   • Release tags are created from main

Project Management

This project uses GitHub's project management features to track issues, pull requests, and milestones. We follow a structured workflow:

1. Issues: Used to track bugs, feature requests, and tasks
2. Pull Requests: Follow our contribution guidelines
3. Milestones: Group related issues and PRs for releases
4. Project Board: Visual kanban board for task tracking
5. Automated Changelog: Updates via GitHub Actions on PR merges

Our changelog follows the Keep a Changelog format and is automatically updated when PRs are merged.

Changelog Management

This repository uses automated changelog generation through GitHub Actions. When you create a PR:

1. Use conventional commit format in PR titles:

   • feat: for new features (increments minor version)
   • fix: for bug fixes (increments patch version)
   • feat!: or include BREAKING CHANGE for breaking changes (increments major version)
   • docs: for documentation changes
   • refactor: for code changes that neither fix bugs nor add features

2. The workflow will automatically:

   • Skip changelog updates for changelog-only PRs
   • Create a new changelog entry based on your PR title and description
   • Increment version number according to semantic versioning
   • Create a new PR with the changelog update

Automated Changelog

This project uses an automated changelog workflow that:

• Updates CHANGELOG.md when PRs are merged to main
• Follows Semantic Versioning for version numbers:
  • Major (X.0.0): Breaking changes (feat! or BREAKING CHANGE)
  • Minor (0.X.0): New features (feat)
  • Patch (0.0.X): Bug fixes and small changes
• Determines change type from PR title:
  • feat: → Added (new features)
  • fix: → Fixed (bug fixes)
  • docs: → Documentation
  • refactor: → Changed
  • security: → Security
  • feat!: or BREAKING CHANGE → Breaking Change
• Creates a new PR with changelog updates
• Follows Keep a Changelog format

For detailed workflow documentation, see GitHub CLI Workflow Guide.

Automated Releases

This project uses GitHub Actions for automated releases. The workflow is triggered when a new tag is pushed and includes:

1. Automated Changelog Generation:

   • Generates changelog from commit messages
   • Includes commit hashes for reference
   • Groups changes by type

2. Quality Checks:

   • Runs ShellCheck on all scripts
   • Validates syntax and best practices
   • Ensures code quality before release

3. Release Creation:

   • Creates GitHub release automatically
   • Includes generated changelog
   • Adds feature list and installation instructions

To create a new release:

1. Make your changes and commit them:

git add .
git commit -m "feat: your feature description"

2. Create and push a new tag:

git tag -a v1.x.x -m "Release description"
git push origin v1.x.x

The workflow will automatically:

• Generate the changelog
• Run quality checks
• Create the release
• Update documentation

Commit Messages

Follow the Conventional Commits specification:

• feat: New features
• fix: Bug fixes
• docs: Documentation changes
• chore: Maintenance tasks
• refactor: Code improvements
• test: Test updates

Development Workflow

Our project follows a structured branching strategy to maintain code quality and automate changelog updates. Here's how to work with our workflow:

Branch Structure

• main: Production-ready code
• develop: Integration branch for features
• feature/*: Individual feature branches
• fix/*: Bug fix branches
• docs/*: Documentation updates

Making Changes

1. Create Feature Branch

   # For new features
   git checkout develop
   git pull origin develop
   git checkout -b feature/your-feature-name
   
   # For documentation changes
   git checkout develop
   git pull origin develop
   git checkout -b docs/update-description

2. Make Changes

   • Follow commit message conventions:
     • feat: for new features
     • fix: for bug fixes
     • docs: for documentation
     • ! or BREAKING CHANGE for breaking changes

   Example commit messages:

   git commit -m "feat: add new container logging"
   git commit -m "fix: resolve startup script issue"
   git commit -m "docs: update workflow guide"
   git commit -m "feat!: change API response format"

3. Push Changes

   git push origin your-branch-name

4. Create Pull Request

   • Create PR to develop branch
   • Use descriptive title following commit conventions
   • Fill out PR template
   • Request review if needed

5. Merge to Develop

   • Ensure CI passes
   • Get approvals if required
   • Merge using "Merge commit"

6. Release to Main

   • Create PR from develop to main
   • Our workflow will:
     • Auto-increment version based on changes
     • Update changelog automatically
     • Create release tag

Changelog Process

The changelog is automatically updated through our GitHub Actions workflow. Here's the complete process:

1. Starting Development

   # Always start from develop
   git checkout develop
   git pull origin develop
   
   # Create your feature branch
   git checkout -b feature/your-feature

2. Making Changes

   # Make your changes
   git add .
   git commit -m "type: description"
   git push origin feature/your-feature

3. Pull Request Flow a. Feature to Develop:

   • Create PR from your feature branch to develop
   • Get review and approval
   • Merge to develop

   b. Develop to Main:

   • Create PR from develop to main
   • Get review and approval
   • Merge to main
   • IMPORTANT: Wait for changelog PR

   c. Changelog Update:

   • Automatic PR will be created
   • Title will be: "docs: update changelog for vX.Y.Z"
   • MUST merge this PR before new changes

4. Version Updates The workflow automatically determines version increments:

   • Major (X.0.0): Breaking changes
   • Minor (x.Y.0): New features
   • Patch (x.y.Z): Bug fixes and docs

5. Important Notes

   • Never skip waiting for the changelog PR
   • Always merge changelog PR before new changes
   • Keep PRs focused and single-purpose
   • Follow commit message conventions

Example Flow:

# Start new feature
git checkout develop
git pull origin develop
git checkout -b feature/new-feature

# Make changes and commit
git add .
git commit -m "feat: add new feature"
git push origin feature/new-feature

# Create PR to develop and wait for merge
# Create PR to main and wait for merge
# Wait for changelog PR and merge it

# Then start next feature
git checkout develop
git pull origin develop
git checkout -b feature/next-feature

Best Practices

1. Branch Naming

   • Features: feature/descriptive-name
   • Fixes: fix/issue-description
   • Docs: docs/update-topic

2. Commit Messages

   • Be descriptive but concise
   • Follow conventional commits
   • Reference issues when applicable

3. PR Guidelines

   • One feature/fix per PR
   • Keep changes focused
   • Update tests if needed
   • Include documentation updates

4. Documentation

   • Update README for new features
   • Keep code comments current
   • Update API docs if changed

Contributing

Please read CONTRIBUTING.md for details on our code of conduct, and the process for submitting pull requests.

License

This project is licensed under the MIT License - see the LICENSE file for details.

Support

If you encounter any problems or have suggestions, please open an issue.