diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 00000000..6f4f85c2 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,21 @@ +## Goal + + +## Changes +- [ ] Bug fix +- [ ] New feature +- [ ] Refactoring +- [ ] Documentation update + +## Testing + +- [ ] Tested locally +- [ ] All existing tests pass + +## Checklist +- [ ] My code follows the project's style guidelines. +- [ ] I have performed a self-review of my own code. +- [ ] I have commented my code, particularly in hard-to-understand areas. +- [ ] PR title is clear, descriptive. +- [ ] Documentation/README updated. +- [ ] No secrets or large temporary files committed. \ No newline at end of file diff --git a/.github/workflows/github-actions-demo.yml b/.github/workflows/github-actions-demo.yml new file mode 100644 index 00000000..d17a778c --- /dev/null +++ b/.github/workflows/github-actions-demo.yml @@ -0,0 +1,39 @@ +name: GitHub Actions Demo +run-name: ${{ github.actor }} is testing out GitHub Actions 🚀 +on: [workflow_dispatch] + +jobs: + Explore-GitHub-Actions: + runs-on: ubuntu-latest + steps: + - run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event." + - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!" + - run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}." + - name: Check out repository code + uses: actions/checkout@v5 + - run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner." + - run: echo "🖥️ The workflow is now ready to test your code on the runner." + - name: List files in the repository + run: | + ls ${{ github.workspace }} + - run: echo "🍏 This job's status is ${{ job.status }}." + - name: Gather system information + run: | + echo "System Information:" + echo "CPU Information:" + lscpu | grep "Model name" + echo "" + echo "Memory Information:" + free -h + echo "" + echo "Operating System Details:" + cat /etc/os-release + echo "" + echo "Kernel Version:" + uname -a + echo "" + echo "Disk Usage:" + df -h + echo "" + echo "CPU Current Load:" + top -bn1 | grep "Cpu(s)" \ No newline at end of file diff --git a/file.txt b/file.txt new file mode 100644 index 00000000..a276accb --- /dev/null +++ b/file.txt @@ -0,0 +1,4 @@ +First commit +Second commit +Third commit +temp diff --git a/labs/image-3.png b/labs/image-3.png new file mode 100644 index 00000000..15cbbc2d Binary files /dev/null and b/labs/image-3.png differ diff --git a/labs/image-4.png b/labs/image-4.png new file mode 100644 index 00000000..a2b3e38c Binary files /dev/null and b/labs/image-4.png differ diff --git a/labs/image-5.png b/labs/image-5.png new file mode 100644 index 00000000..5990db8f Binary files /dev/null and b/labs/image-5.png differ diff --git a/labs/submission1.md b/labs/submission1.md new file mode 100644 index 00000000..b43b876f --- /dev/null +++ b/labs/submission1.md @@ -0,0 +1,7 @@ +1. Signing commits allows others to confidently trust that changes come from a verified source, as GitHub marks them with a "Verified" status. It provides persistent cryptographic verification of a commit's origin within the repository's network. +2. I've lost the logs of setuping the ssh key, but I wouldn't be able to clone the repository without it. Here's the logs of verified commit: + [main f2ef5b1] docs: add commit signing summary + 1 file changed, 2 insertions(+) + create mode 100644 labs/submission1.md +3. Commit signing is important in DevOps workflows because it cryptographically verifies the identity of the author, ensuring the integrity and authenticity of code changes. This creates a trusted audit trail and is often required for security compliance and secure deployments. +4. https://github.com/fleeshka/DevOps-Intro/commit/f2ef5b1daca3b8f106c8663865a702291915d550 "This commit was signed with the committer's verified signature. fleeshka SSH Key Fingerprint: epWa0oYt9UaQ5sHNWrIdXl0Vvaz6tQMrpp2dhwg7KUQ Verified on Feb 6, 2026, 05:38 PM" \ No newline at end of file diff --git a/labs/submission2.md b/labs/submission2.md new file mode 100644 index 00000000..533e2acc --- /dev/null +++ b/labs/submission2.md @@ -0,0 +1,283 @@ +# 1.2: + +1. All command outputs for object inspection.: +- commit +``` +git cat-file -p 08d3851 +tree de914b4b2283bf5347f7f5b32c8009c0eb3df1d5 +parent 9a01abcd8d3ec399cb0db5d38fce30408b719608 +author fleeshka 1771148530 +0300 +committer fleeshka 1771148530 +0300 +gpgsig -----BEGIN SSH SIGNATURE----- + U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgujrrBf24qaqo3iTuauxWwmVU/r + 08NAjJ8hGJsihW/noAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5 + AAAAQO4jDhX46NZtXpN57J5yrLd+TikkqI2b3PM5Y5I8w0jOZKQGg/TLZN15X9FeV1eJgt + rG8dqy2O5PbYd9+a9ehQ4= + -----END SSH SIGNATURE----- + +Add test file +``` +- tree +``` +git cat-file -p de914b4b2283bf5347f7f5b32c8009c0eb3df1d5 +040000 tree 2bcb538ae49751bc18a51a8373b883319008572b .github +100644 blob 6e60bebec0724892a7c82c52183d0a7b467cb6bb README.md +040000 tree a1061247fd38ef2a568735939f86af7b1000f83c app +040000 tree a009361d37744f32572f5255e50bd5f701d1c701 labs +040000 tree d3fb3722b7a867a83efde73c57c49b5ab3e62c63 lectures +100644 blob 2eec599a1130d2ff231309bb776d1989b97c6ab2 test.txt +``` +- blob +``` +git cat-file -p 2eec599a1130d2ff231309bb776d1989b97c6ab2 +Test content +``` +2. Blob is an object that stores the exact contents of a file without any filename or directory information. Tree is an object that represents a directory, mapping filenames to blobs or other trees along with their permissions, thus defining the project’s structure at a specific snapshot. Commit is an object that points to a tree and records metadata such as parent commit(s), author, committer, message, and optional signature, forming a node in the repository’s history graph. +3. Git stores repository data as a content-addressable object database, where every file snapshot, directory structure, and commit is saved as a compressed object identified by a cryptographic hash of its contents. This design enables immutability, efficient deduplication of identical data, and the construction of history as a chain of commits that reference trees and parent commits rather than storing full copies of the project each time. +4. +- blob content (test.txt): +``` +git cat-file -p 2eec599a1130d2ff231309bb776d1989b97c6ab2 +Test content +``` +- tree content (.github): +``` +git cat-file -p 2bcb538ae49751bc18a51a8373b883319008572b +100644 blob 6f4f85c2442956ce747ef407b3d63766199b059c pull_request_template.md +``` +- commit content (same as first code snapshot from task 1): +``` +git cat-file -p 08d3851 +tree de914b4b2283bf5347f7f5b32c8009c0eb3df1d5 +parent 9a01abcd8d3ec399cb0db5d38fce30408b719608 +author fleeshka 1771148530 +0300 +committer fleeshka 1771148530 +0300 +gpgsig -----BEGIN SSH SIGNATURE----- + U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgujrrBf24qaqo3iTuauxWwmVU/r + 08NAjJ8hGJsihW/noAAAADZ2l0AAAAAAAAAAZzaGE1MTIAAABTAAAAC3NzaC1lZDI1NTE5 + AAAAQO4jDhX46NZtXpN57J5yrLd+TikkqI2b3PM5Y5I8w0jOZKQGg/TLZN15X9FeV1eJgt + rG8dqy2O5PbYd9+a9ehQ4= + -----END SSH SIGNATURE----- + +Add test file +``` + +# 2.2: + +1. +``` +git switch -c git-reset-practice +Switched to a new branch 'git-reset-practice' + +echo "First commit" > file.txt && git add file.txt && git commit -m "First commit" +[git-reset-practice 3ab8bfa] First commit + 1 file changed, 1 insertion(+) + create mode 100644 file.txt + +echo "Second commit" >> file.txt && git add file.txt && git commit -m "Second commit" +[git-reset-practice 492e2b3] Second commit + 1 file changed, 1 insertion(+) + +echo "Third commit" >> file.txt && git add file.txt && git commit -m "Third commit" +[git-reset-practice 85b268c] Third commit + 1 file changed, 1 insertion(+) + +git reset --soft HEAD~1 + +git reset --hard HEAD~1 +HEAD is now at 3ab8bfa First commit + +git reflog +3ab8bfa (HEAD -> git-reset-practice) HEAD@{0}: reset: moving to HEAD~1 +492e2b3 HEAD@{1}: reset: moving to HEAD~1 +85b268c HEAD@{2}: commit: Third commit +492e2b3 HEAD@{3}: commit: Second commit +3ab8bfa (HEAD -> git-reset-practice) HEAD@{4}: commit: First commit +08d3851 (main) HEAD@{5}: checkout: moving from main to git-reset-practice +08d3851 (main) HEAD@{6}: commit: Add test file +9a01abc (origin/main, origin/HEAD) HEAD@{7}: clone: from github.com:fleeshka/DevOps-Intro.git + +git reset --hard 85b268c +HEAD is now at 85b268c Third commit +``` + +I created a separate branch to safely experiment with history rewriting, then made three sequential commits to generate a clear commit chain for testing. + +I ran git reset --soft HEAD~1 to move the branch pointer back one commit while keeping changes staged, and then git reset --hard HEAD~1 to move back again while discarding both the index and working directory changes. + +Finally, I used git reflog to locate the previous commit state and git reset --hard 85b268c to restore the branch to the lost “Third commit,” demonstrating how reflog enables recovery after destructive resets. + +2. +``` +git log --oneline +85b268c (HEAD -> git-reset-practice) Third commit +492e2b3 Second commit +3ab8bfa First commit +08d3851 (main) Add test file +9a01abc (origin/main, origin/HEAD) Merge pull request #1 from fleeshka/feature/lab1 +47dfc6f docs: add lab1 submission stub +9a18fea docs: add commit signing summary +f2ef5b1 docs: add commit signing summary +d6b6a03 Update lab2 +87810a0 feat: remove old Exam Exemption Policy +1e1c32b feat: update structure +6c27ee7 feat: publish lecs 9 & 10 +1826c36 feat: update lab7 +3049f08 feat: publish lec8 +da8f635 feat: introduce all labs and revised structure +04b174e feat: publish lab and lec #5 +67f12f1 feat: publish labs 4&5, revise others +82d1989 feat: publish lab3 and lec3 +3f80c83 feat: publish lec2 +499f2ba feat: publish lab2 +af0da89 feat: update lab1 +74a8c27 Publish lab1 +f0485c0 Publish lec1 +31dd11b Publish README.md +``` +``` +git reflog +85b268c (HEAD -> git-reset-practice) HEAD@{0}: reset: moving to 85b268c +3ab8bfa HEAD@{1}: reset: moving to HEAD~1 +492e2b3 HEAD@{2}: reset: moving to HEAD~1 +85b268c (HEAD -> git-reset-practice) HEAD@{3}: commit: Third commit +492e2b3 HEAD@{4}: commit: Second commit +3ab8bfa HEAD@{5}: commit: First commit +08d3851 (main) HEAD@{6}: checkout: moving from main to git-reset-practice +08d3851 (main) HEAD@{7}: commit: Add test file +9a01abc (origin/main, origin/HEAD) HEAD@{8}: clone: from github.com:fleeshka/DevOps-Intro.git +``` + +3. +- git reset --soft HEAD~1 moved the branch pointer back one commit in history while leaving both the index (staging area) and working tree unchanged, so the reverted commit’s changes remained staged. +- git reset --hard HEAD~1 then moved history back again and forcibly aligned both the index and working tree to that earlier commit, discarding any staged or working directory changes introduced by the removed commits. + +4. The recovery worked because git reflog records every movement of HEAD, including resets that rewrite branch history, even when commits become unreachable from the current branch tip. After the --soft and --hard resets moved the branch from the Third commit to the First commit, the Third commit (85b268c) was no longer visible in normal git log, but it still appeared in the reflog as HEAD@{2}. By identifying that hash in the reflog and running git reset --hard 85b268c, the branch pointer, index, and working tree were all restored to the exact state of the lost commit, effectively undoing the destructive reset. + +# 3: + +1, 2. +``` +git log --oneline --graph --all +* 54279f3 (side-branch) Side branch commit +* 85b268c (HEAD -> git-reset-practice) Third commit +* 492e2b3 Second commit +* 3ab8bfa First commit +* 08d3851 (main) Add test file +* 9a01abc (origin/main, origin/HEAD) Merge pull request #1 from fleeshka/feature/lab1 +|\ +| | * 4b587d9 (origin/feature/lab1) docs: update submission, finalize +| | * add170f docs: add lab1 submission stub +| |/ +| * 47dfc6f docs: add lab1 submission stub +|/ +* 9a18fea docs: add commit signing summary +* f2ef5b1 docs: add commit signing summary +* d6b6a03 Update lab2 +* 87810a0 feat: remove old Exam Exemption Policy +* 1e1c32b feat: update structure +* 6c27ee7 feat: publish lecs 9 & 10 +* 1826c36 feat: update lab7 +* 3049f08 feat: publish lec8 +* da8f635 feat: introduce all labs and revised structure +* 04b174e feat: publish lab and lec #5 +* 67f12f1 feat: publish labs 4&5, revise others +* 82d1989 feat: publish lab3 and lec3 +* 3f80c83 feat: publish lec2 +* 499f2ba feat: publish lab2 +* af0da89 feat: update lab1 +* 74a8c27 Publish lab1 +* f0485c0 Publish lec1 +* 31dd11b Publish README.md +``` + +3. Graph view makes the commit structure visually explicit, clearly showing where branches diverge, merge, and how git-reset-practice, side-branch, and main relate to each other. Seeing history as a graph rather than a linear list makes it much easier to understand how resets move branch pointers and how commits remain in the repository even when they are no longer at the tip of a branch. + +# 4: + +1. +``` +git tag v1.0.0 + +git push origin v1.0.0 +Enumerating objects: 13, done. +Counting objects: 100% (13/13), done. +Delta compression using up to 16 threads +Compressing objects: 100% (8/8), done. +Writing objects: 100% (12/12), 1.38 KiB | 706.00 KiB/s, done. +Total 12 (delta 7), reused 0 (delta 0), pack-reused 0 +remote: Resolving deltas: 100% (7/7), completed with 1 local object. +To github.com:fleeshka/DevOps-Intro.git + * [new tag] v1.0.0 -> v1.0.0 + +echo "temp" >> file.txt && git add file.txt && git commit -m "for v1.1.0" +[git-reset-practice 697f986] for v1.1.0 + 1 file changed, 1 insertion(+) + +git tag v1.1.0 + +git push origin v1.1.0 +Enumerating objects: 5, done. +Counting objects: 100% (5/5), done. +Delta compression using up to 16 threads +Compressing objects: 100% (2/2), done. +Writing objects: 100% (3/3), 524 bytes | 524.00 KiB/s, done. +Total 3 (delta 1), reused 0 (delta 0), pack-reused 0 +remote: Resolving deltas: 100% (1/1), completed with 1 local object. +To github.com:fleeshka/DevOps-Intro.git + * [new tag] v1.1.0 -> v1.1.0 +``` +2. +85b268c0b137b8b066cf747d045311e1b3db049d +697f986e8bf3203e50b0f0a2208494dab41e800f + +3. +Git tags are essential for marking specific points in your repository's history as important releases, enabling clear versioning that makes it easy to identify and rollback to stable versions. In CI/CD pipelines, tags often trigger automated deployment processes, and they serve as anchor points for generating release notes by comparing changes between tagged versions. + +# 5: + +1. +``` +git switch -c cmd-compare +Switched to a new branch 'cmd-compare' + +git switch - +Switched to branch 'git-reset-practice' + +echo "scratch" >> demo.txt +git add demo.txt +git restore demo.txt +git restore --staged demo.txt +``` + +2. +``` +git status +On branch git-reset-practice +Untracked files: + (use "git add ..." to include in what will be committed) + **Deliverable:** + demo.txt + labs/submission2.md + witch -c cmd-compare + +nothing added to commit but untracked files present (use "git add" to track) + +git branch + cmd-compare +* git-reset-practice + main + side-branch +``` + +3. +- git restore demo.txt is used when you want to permanently discard all uncommitted changes in your working directory and revert the file back to its last committed state. +- git restore --staged demo.txt is used when you want to remove a file from the staging area while preserving all your local changes in the working directory. +- git restore --source=HEAD~1 demo.txt is used when you need to revert a file to exactly how it appeared in a previous commit, whether to undo unwanted changes or recover a deleted file. + +# 6: + +all done + +# GitHub Community +Starring repositories matters in open source because it serves as both a personal bookmarking system for interesting projects and a public signal of appreciation that helps projects gain visibility, attract contributors, and build community trust through higher star counts. Following developers is essential in team projects and professional growth as it enables you to learn from experienced developers' code, discover new tools and trends, build valuable professional connections, and demonstrate your engagement with the developer community to potential employers. diff --git a/labs/submission3.md b/labs/submission3.md new file mode 100644 index 00000000..70444648 --- /dev/null +++ b/labs/submission3.md @@ -0,0 +1,62 @@ +# 1: + +1. https://github.com/fleeshka/DevOps-Intro/actions/runs/22035534716 +![successful pipeline](image.png) + +2. From this quickstart, I learned that GitHub Actions uses jobs (like "Explore-GitHub-Actions") which are sets of steps that run on a virtual machine called a runner (ubuntu-latest), and these workflows are automatically triggered by events such as triggers (like on: [push]). The steps can execute shell commands, check out repository code using actions like actions/checkout, and use contextual variables like ${{ github.event_name }} to access information about the workflow run. + +3. A push event to the repository triggered the workflow run. + +4. The workflow execution process begins when a push event triggers the workflow, which then launches a job on an Ubuntu runner that sequentially executes each step, including running echo commands, checking out the repository code with actions/checkout, and listing files in the workspace. + +# 2: + +1. Remove push trigger, added manual workflow_dispatch trigger, added a new step Gather system information + +2. +``` +System Information: +CPU Information: +Model name: AMD EPYC 7763 64-Core Processor + +Memory Information: + total used free shared buff/cache available +Mem: 15Gi 999Mi 13Gi 39Mi 1.8Gi 14Gi +Swap: 3.0Gi 0B 3.0Gi + +Operating System Details: +PRETTY_NAME="Ubuntu 24.04.3 LTS" +NAME="Ubuntu" +VERSION_ID="24.04" +VERSION="24.04.3 LTS (Noble Numbat)" +VERSION_CODENAME=noble +ID=ubuntu +ID_LIKE=debian +HOME_URL="https://www.ubuntu.com/" +SUPPORT_URL="https://help.ubuntu.com/" +BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" +PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" +UBUNTU_CODENAME=noble +LOGO=ubuntu-logo + +Kernel Version: +Linux runnervmjduv7 6.14.0-1017-azure #17~24.04.1-Ubuntu SMP Mon Dec 1 20:10:50 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux + +Disk Usage: +Filesystem Size Used Avail Use% Mounted on +/dev/root 145G 53G 92G 37% / +tmpfs 7.9G 84K 7.9G 1% /dev/shm +tmpfs 3.2G 1008K 3.2G 1% /run +tmpfs 5.0M 0 5.0M 0% /run/lock +efivarfs 128M 32K 128M 1% /sys/firmware/efi/efivars +/dev/sda16 881M 63M 757M 8% /boot +/dev/sda15 105M 6.2M 99M 6% /boot/efi +tmpfs 1.6G 12K 1.6G 1% /run/user/1001 + +CPU Current Load: +%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni,100.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st +``` + +3. Manual triggers (workflow_dispatch) give control over when a workflow runs by requiring explicit user action through the GitHub UI, while automatic triggers (like push) execute workflows immediately whenever specified events occur in the repository without human intervention. + +4. The GitHub Actions runner provides a powerful cloud-hosted virtual environment with an AMD EPYC 64-core processor, 15GB of RAM, and 145GB of storage running Ubuntu 24.04 LTS on Azure infrastructure. With near-idle CPU usage (100% idle), minimal memory consumption (only ~1GB used), and Ubuntu 24.04 with kernel 6.14, this runner offers robust performance capabilities suitable for building, testing, and deploying applications without resource constraints. diff --git a/labs/submission4.md b/labs/submission4.md new file mode 100644 index 00000000..ed68ebcf --- /dev/null +++ b/labs/submission4.md @@ -0,0 +1,223 @@ +# 1. + +1. + +``` +systemd-analyze +Startup finished in 7.518s (firmware) + 2.828s (loader) + 5.312s (kernel) + 11.465s (userspace) = 27.124s +graphical.target reached after 11.433s in userspace. +``` +``` +systemd-analyze blame +31.188s apt-daily-upgrade.service +23.699s systemd-suspend.service +14.817s fstrim.service + 3.607s NetworkManager-wait-online.service +... +``` +``` +uptime + 16:58:52 up 5 days, 17:41, 1 user, load average: 1.44, 1.17, 1.98 +``` +``` +w + 16:59:05 up 5 days, 17:41, 1 user, load average: 1.59, 1.21, 1.98 +USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT +fateee tty2 - 15:30 5days 0.01s 0.01s /usr/libexec/gn +``` +``` +ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 6 + PID PPID CMD %MEM %CPU + 39280 38752 /snap/firefox/7836/usr/lib/ 12.1 24.2 + 38548 37733 /snap/firefox/7836/usr/lib/ 4.8 57.0 + 38774 38752 /snap/firefox/7836/usr/lib/ 2.9 1.3 + 43914 43542 /usr/share/code/code /home/ 2.3 10.9 + 37733 3571 /usr/bin/gnome-shell 2.3 20.8 +``` +``` +ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -n 6 + PID PPID CMD %MEM %CPU + 38548 37733 /snap/firefox/7836/usr/lib/ 4.8 56.9 + 42864 42755 /usr/share/code/code --type 2.1 24.8 + 39280 38752 /snap/firefox/7836/usr/lib/ 12.1 24.2 + 37733 3571 /usr/bin/gnome-shell 2.3 20.8 + 42979 42747 /proc/self/exe --type=utili 0.7 12.3 +``` +``` +systemctl list-dependencies +default.target +● ├─accounts-daemon.service +● ├─gdm.service +● ├─gnome-remote-desktop.service +● ├─ollama.service +● ├─power-profiles-daemon.service +... +``` +``` +systemctl list-dependencies multi-user.target +multi-user.target +○ ├─anacron.service +● ├─apport.service +● ├─avahi-daemon.service +● ├─console-setup.service +● ├─containerd.service +... +``` +``` +who -a + system boot 2026-02-17 23:17 + run-level 5 2026-02-17 23:18 +fateee ? seat0 2026-02-23 15:30 ? 37587 (login screen) +fateee + tty2 2026-02-23 15:30 old 37587 (tty2) +``` +``` +last -n 5 +fateee tty2 tty2 Mon Feb 23 15:30 still logged in +fateee seat0 login screen Mon Feb 23 15:30 still logged in +fateee tty2 tty2 Tue Feb 17 23:20 - 15:30 (5+16:10) +fateee seat0 login screen Tue Feb 17 23:20 - 15:30 (5+16:10) +reboot system boot 6.14.0-37-generi Tue Feb 17 23:17 still running + +wtmp begins Sat Nov 30 02:41:30 2024 +``` +``` +free -h + total used free shared buff/cache available +Mem: 14Gi 8.1Gi 2.7Gi 128Mi 4.0Gi 6.9Gi +Swap: 4.0Gi 21Mi 4.0Gi +``` +``` +cat /proc/meminfo | grep -e MemTotal -e SwapTotal -e MemAvailable +MemTotal: 15706372 kB +MemAvailable: 7199052 kB +SwapTotal: 4194300 kB +``` + +2. + +- The system takes 27 seconds to boot, with userspace taking the longest at 11.5 seconds, and the boot process is significantly slowed by several services with apt-daily-upgrade.service taking an unusually long 31 seconds to run. + +- The system has been running continuously for over 5 days with a single user logged in, and while the load averages (1.44, 1.17, 1.98) indicate moderate system activity, the 5-day idle time on the display manager suggests the user is likely away from an active graphical session. + +- Firefox processes dominate system resource usage, with one instance consuming 12.1% of memory and another using 57% CPU, while GNOME Shell and VS Code also contribute significantly to the overall system load. + +- The system boots into a graphical (default.target) environment with GNOME-related services and Ollama running, while the multi-user.target shows a mix of essential system services along with container runtimes (containerd) and crash reporting tools (apport) configured to start at boot. + +- The system was last booted on February 17th and has been running continuously for 5 days, with user fateee logging in at 15:30 today after a previous session lasting over 5 days, confirming the system's prolonged uptime and the user's recent return to an active session. + +- The system has 14GB of RAM with 8.1GB currently used, but 6.9GB is still available thanks to 4GB of cached memory, while swap usage is minimal at only 21MB out of 4GB total. + +3. + +The top memory-consuming process is a Firefox process (PID 39280) using 12.1% of memory. + +4. + +Firefox dominates both memory and CPU usage with multiple processes, while GNOME Shell and VS Code also contribute consistently to system load, indicating a typical desktop workload with web browsing and development activities. + +# 2. + +1. + +``` +traceroute github.com +traceroute to github.com (140.82.121.3), 30 hops max, 60 byte packets + 1 _gateway (192.168.0.1) 2.510 ms 2.439 ms 2.392 ms + 2 10.16.255.152 (10.16.255.152) 7.198 ms 7.156 ms 7.109 ms + 3 10.16.238.38 (10.16.238.38) 7.583 ms 10.16.238.78 (10.16.238.78) 10.656 ms 10.16.238.94 (10.16.238.94) 7.493 ms + 4 10.16.248.150 (10.16.248.150) 7.784 ms 7.738 ms 10.16.248.218 (10.16.248.218) 7.686 ms + 5 10.16.248.189 (10.16.248.189) 13.930 ms * 10.16.248.134 (10.16.248.134) 8.126 ms + ... +``` +``` +dig github.com + +; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> github.com +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51756 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 65494 +;; QUESTION SECTION: +;github.com. IN A + +;; ANSWER SECTION: +github.com. 29 IN A 140.82.121.4 + +;; Query time: 7 msec +;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) +;; WHEN: Mon Feb 23 17:09:11 MSK 2026 +;; MSG SIZE rcvd: 55 +``` +``` +sudo timeout 10 tcpdump -c 5 -i any 'port 53' -nn +tcpdump: data link type LINUX_SLL2 +tcpdump: verbose output suppressed, use -v[v]... for full protocol decode +listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes + +0 packets captured +0 packets received by filter +0 packets dropped by kernel +``` +``` +dig -x 8.8.4.4 + +; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -x 8.8.4.4 +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47428 +;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 65494 +;; QUESTION SECTION: +;4.4.8.8.in-addr.arpa. IN PTR + +;; ANSWER SECTION: +4.4.8.8.in-addr.arpa. 7658 IN PTR dns.google. + +;; Query time: 7 msec +;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) +;; WHEN: Mon Feb 23 17:10:10 MSK 2026 +;; MSG SIZE rcvd: 73 +``` +``` +dig -x 1.1.2.2 + +; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> -x 1.1.2.2 +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28957 +;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 65494 +;; QUESTION SECTION: +;2.2.1.1.in-addr.arpa. IN PTR + +;; AUTHORITY SECTION: +1.in-addr.arpa. 736 IN SOA ns.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 23597 7200 1800 604800 3600 + +;; Query time: 66 msec +;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) +;; WHEN: Mon Feb 23 17:10:22 MSK 2026 +;; MSG SIZE rcvd: 137 +``` + +2. + +The network path to GitHub traverses through multiple private (10.x.x.x) and carrier-grade NAT hops before reaching international routing in Germany, with significant latency increases and packet loss occurring after hop 12, suggesting possible network congestion or filtering. + +3. + +DNS queries are being resolved quickly (7ms) through the local stub resolver (127.0.0.53), with no observed DNS traffic during the capture period indicating either cached responses or inactive DNS queries at that moment. + +4. + +The reverse lookup for 8.8.4.4 returns a successful NOERROR status but provides no answer section, indicating that while the DNS query was processed correctly, there is no PTR record configured for this IP address. + +5. + +Since no packets were captured by tcpdump, I cannot provide a specific DNS query example from the packet capture. If there were packets captured, I would extract a DNS query example by examining the tcpdump output. \ No newline at end of file diff --git a/labs/submission5.md b/labs/submission5.md new file mode 100644 index 00000000..4ad80535 --- /dev/null +++ b/labs/submission5.md @@ -0,0 +1,40 @@ +# 1. + +1. Ubuntu 24.04.3 LTS + +2. VirtualBox Graphical User Interface Version 7.0.16_Ubuntu + +# 2. + +1. CPU Details: Processor model, architecture, cores, frequency + +- model name : AMD Ryzen 7 4800 with Radeon Graphics (from cat /proc/cpuinfo) +- architecture : x86_64 (from uname -m) +- cores : 4 (from cat /proc/cpuinfo) +- frequency : 1794.714 (from cat /proc/cpuinfo) + +2. Memory Information: Total RAM, available memory + +- Total RAM : 8130672 kB (from cat /proc/meminfo) +- available memory : 6981908 kB (from cat /proc/meminfo) + +3. Network Configuration: IP addresses, network interfaces + +- IP addresses : 10.0.2.15 (from ip -br addr) +- network interfaces : lo, enp0s3 (from ip -br addr) + +4. Storage Information: Disk usage, filesystem details + +- Disk usage : Size: 40G, Used: 11G, Avail: 27G (from df -h) +- filesystem details : types: tmpfs, ext4. used: 11m+ (from df -T) + +5. Operating System: Ubuntu version, kernel information + +- Ubuntu version : Ubuntu 24.04.4 LTS (from lsb_release -a) +- kernel information : Linux devops-VirtualBox 6.17.0-14-generic... GNU/Linux (from uname -a) + +6. Virtualization Detection: Confirmation system is running in a VM + +- systemd-detect-virt outputs oracle, which means my system is indeed is running in an Oracle VM VirtualBox machine. + +### The /proc filesystem proved most useful for CPU and memory details, providing direct access to hardware information through /proc/cpuinfo and /proc/meminfo, while the ip command was invaluable for network configuration with its clean, concise output format, and systemd-detect-virt was the most straightforward tool for confirming virtualization, clearly identifying the Oracle VM environment with a single command. \ No newline at end of file diff --git a/labs/submission6.md b/labs/submission6.md new file mode 100644 index 00000000..f2bcd69b --- /dev/null +++ b/labs/submission6.md @@ -0,0 +1,211 @@ +# 1 + +1.1: +``` +docker ps -a +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +``` +``` +docker images +REPOSITORY TAG IMAGE ID CREATED SIZE +postgres 15 d743cd41504b 2 weeks ago 445MB +...(it's a big list, I've been using Docker for a while now) +``` + +1.2 + +``` +REPOSITORY TAG IMAGE ID CREATED SIZE +ubuntu latest bbdabce66f1b 4 weeks ago 78.1MB +``` + +1.3 +77MB (tar) vs 78.1MB (image) + +1.4 Error response from daemon: conflict: unable to remove repository reference "ubuntu:latest" (must force) - container 38b408c17591 is using its referenced image bbdabce66f1b + +1.5 This error occurs because a container is a running or stopped instance that depends on the image's layers to exist, and Docker prevents image removal to avoid breaking the container's ability to restart or access its filesystem. + +1.6 The exported tar file contains all the image layers, metadata, and configuration needed to recreate the exact image, essentially a complete snapshot of the image's filesystem. + + +# 2 + +2.1: + +``` + + + +Welcome to nginx! + + + +

Welcome to nginx!

+

If you see this page, nginx is successfully installed and working. +Further configuration is required for the web server, reverse proxy, +API gateway, load balancer, content cache, or other features.

+ +

For online documentation and support please refer to +nginx.org.
+To engage with the community please visit +community.nginx.org.
+For enterprise grade support, professional services, additional +security features and capabilities please refer to +f5.com/nginx.

+ +

Thank you for using nginx.

+ + +``` + +2.2 + +``` +curl http://localhost + + +The best + + +

website

+ + +``` + +2.3 + +``` +docker diff my_website_container +C /etc +C /etc/nginx +C /etc/nginx/conf.d +C /etc/nginx/conf.d/default.conf +C /run +C /run/nginx.pid +``` + +2.4 The configuration files in /etc show as "Changed" because Nginx automatically modifies its own config files and creates runtime settings when the container starts. The /run/nginx.pid file appears as "Changed" because it's dynamically created when the Nginx process runs to store the process ID, which changes each time the container starts. + +2.5 Docker commit offers quick snapshots for testing but creates non-reproducible, opaque images, while Dockerfile provides version-controlled, automated, and documented builds that are essential for production and collaboration. + +# 3 + +3.1 +``` +docker exec container1 ping -c 3 container2 +PING container2 (172.22.0.2): 56 data bytes +64 bytes from 172.22.0.2: seq=0 ttl=64 time=0.175 ms +64 bytes from 172.22.0.2: seq=1 ttl=64 time=0.179 ms +64 bytes from 172.22.0.2: seq=2 ttl=64 time=0.165 ms + +--- container2 ping statistics --- +3 packets transmitted, 3 packets received, 0% packet loss +round-trip min/avg/max = 0.165/0.173/0.179 ms +``` + +3.2 +``` +docker network inspect lab_network +[ + { + "Name": "lab_network", + "Id": "a5f7f43a8c165fadeaa2bfebb9474b1d2f75a1776f42bb849d67c0667c87ca26", + "Created": "2026-03-13T16:02:10.103323733+03:00", + "Scope": "local", + "Driver": "bridge", + "EnableIPv4": true, + "EnableIPv6": false, + "IPAM": { + "Driver": "default", + "Options": {}, + "Config": [ + { + "Subnet": "172.22.0.0/16", + "Gateway": "172.22.0.1" + } + ] + }, + "Internal": false, + "Attachable": false, + "Ingress": false, + "ConfigFrom": { + "Network": "" + }, + "ConfigOnly": false, + "Containers": { + "4fc70f9ba2556de1d7420a27c07bb2f32284d210c4a159dc695ad2510d31d1db": { + "Name": "container2", + "EndpointID": "03d54a1c35f19fd96665d65bd427f3de0c88c526c6f60c322a0290d24aced8cb", + "MacAddress": "ba:4d:03:23:ba:2b", + "IPv4Address": "172.22.0.2/16", + "IPv6Address": "" + }, + "bdd6aecbecfbd8cb4ff166d4a6acd90ff43262db54a5da215c5a7081cd7b5ce6": { + "Name": "container1", + "EndpointID": "eff56a2d8580ae70eca76e6cb9359f799c7ca070fef0401d408bf5a291c269bb", + "MacAddress": "de:63:9a:1a:3d:00", + "IPv4Address": "172.22.0.3/16", + "IPv6Address": "" + } + }, + "Options": {}, + "Labels": {} + } +] +``` + +3.3 +``` +ocker exec container1 nslookup container2 +Server: 127.0.0.11 +Address: 127.0.0.11:53 + +Non-authoritative answer: +Name: container2 +Address: 172.22.0.2 + +Non-authoritative answer: +``` + +3.4 Docker's internal DNS server automatically resolves container names to their IP addresses when containers are on the same user-defined network, enabling reliable service discovery without hardcoding IPs. + +3.5 User-defined bridge networks provide automatic DNS resolution between containers (allowing name-based communication), better isolation by grouping related containers, and the ability to dynamically attach/detach containers without restarting. + +# 4 + +4.1 + +``` +

Persistent Data

+``` + +4.2 +``` +curl http://localhost +

Persistent Data

+``` + +4.3 +``` +docker volume inspect app_data +[ + { + "CreatedAt": "2026-03-13T16:07:50+03:00", + "Driver": "local", + "Labels": null, + "Mountpoint": "/var/lib/docker/volumes/app_data/_data", + "Name": "app_data", + "Options": null, + "Scope": "local" + } +] +``` + +4.4 Data persistence is important in containerized applications because containers are ephemeral by nature—when a container is removed, all its internal data is lost, making volumes essential for preserving databases, user uploads, logs, and configuration across container restarts, recreations, or updates. + +4.5 Container storage (ephemeral) exists only as long as the container lives and is perfect for temporary/scratch data, bind mounts link a specific host directory into the container and are ideal for development with live code syncing, while volumes are completely managed by Docker, stored safely in its area, and provide the best persistence, portability, and performance for production data like databases. \ No newline at end of file diff --git a/labs/submission7.md b/labs/submission7.md new file mode 100644 index 00000000..74fb0bf8 --- /dev/null +++ b/labs/submission7.md @@ -0,0 +1,115 @@ +# 1 + +1.1 + +desired-state: +``` +version: 1.0 +app: myapp +replicas: 3 +``` + +current-state: +``` +version: 2.0 +app: myapp +replicas: 5 +``` + +1.2 +``` +./reconcile.sh +diff desired-state.txt current-state.txt +Fri 20 Mar 2026 18:33:17 MSK - ⚠️ DRIFT DETECTED! +Reconciling current state with desired state... +Fri 20 Mar 2026 18:33:17 MSK - ✅ Reconciliation complete +``` + +1.3 +``` +cat current-state.txt +version: 1.0 +app: myapp +replicas: 3 +``` + +1.4 +``` +Fri 20 Mar 2026 18:38:16 MSK - ⚠️ DRIFT DETECTED! +Reconciling current state with desired state... +Fri 20 Mar 2026 18:38:16 MSK - ✅ Reconciliation complete +``` + +1.5 +The GitOps reconciliation loop continuously compares the desired state stored in Git (the source of truth) against the actual live cluster state, automatically correcting any discrepancies by reapplying the desired configuration, thereby preventing configuration drift by ensuring that any manual changes or unauthorized modifications are immediately overwritten to match the declared intent. + +1.6 +Declarative configuration provides advantages over imperative commands in production by specifying the desired end state, enabling version control, automated reconciliation, idempotent application, and consistent environments across the fleet, whereas imperative commands require manual step-by-step execution that is error-prone, unrepeatable, and difficult to audit or rollback. + +# 2 + +2.1 +``` +cat healthcheck.sh +#!/bin/bash +# healthcheck.sh - Monitor GitOps sync health + +DESIRED_MD5=$(md5sum desired-state.txt | awk '{print $1}') +CURRENT_MD5=$(md5sum current-state.txt | awk '{print $1}') + +if [ "$DESIRED_MD5" != "$CURRENT_MD5" ]; then + echo "$(date) - ❌ CRITICAL: State mismatch detected!" | tee -a health.log + echo " Desired MD5: $DESIRED_MD5" | tee -a health.log + echo " Current MD5: $CURRENT_MD5" | tee -a health.log +else + echo "$(date) - ✅ OK: States synchronized" | tee -a health.log +fi +``` + +2.2 +``` +cat health.log +Fri 20 Mar 2026 18:42:29 MSK - ✅ OK: States synchronized +``` + +2.3 +``` +cat health.log +Fri 20 Mar 2026 18:42:45 MSK - ❌ CRITICAL: State mismatch detected! + Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155 + Current MD5: 48168ff3ab5ffc0214e81c7e2ee356f5 +``` + +2.4 +``` +cat health.log +Fri 20 Mar 2026 18:42:29 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:42:45 MSK - ❌ CRITICAL: State mismatch detected! + Desired MD5: a15a1a4f965ecd8f9e23a33a6b543155 + Current MD5: 48168ff3ab5ffc0214e81c7e2ee356f5 +Fri 20 Mar 2026 18:42:49 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:43:28 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:43:31 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:43:34 MSK - ✅ OK: States synchronized +``` + +2.5 +``` +./monitor.sh +Starting GitOps monitoring... +\n--- Check #1 --- +Fri 20 Mar 2026 18:43:28 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:43:28 MSK - ✅ States synchronized +\n--- Check #2 --- +Fri 20 Mar 2026 18:43:31 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:43:31 MSK - ✅ States synchronized +\n--- Check #3 --- +Fri 20 Mar 2026 18:43:34 MSK - ✅ OK: States synchronized +Fri 20 Mar 2026 18:43:34 MSK - ✅ States synchronized +``` + +2.6 +Checksums (MD5) help detect configuration changes by generating a unique, fixed-size hash of the file contents, allowing the health check script to quickly and reliably compare the desired state and current state for any discrepancy—even a single character change—without needing to perform a line-by-line diff, enabling immediate drift detection. + +2.7 +This MD5-based health check directly mirrors how GitOps tools like ArgoCD use hash comparisons to determine "Sync Status" - green when desired and live state checksums match, and red or "OutOfSync" when they diverge. \ No newline at end of file diff --git a/labs/submission8.md b/labs/submission8.md new file mode 100644 index 00000000..fbb4f197 --- /dev/null +++ b/labs/submission8.md @@ -0,0 +1,34 @@ +# 1 + +1.1: +- CPU: firefox, gnome, htop +- Memory: firefox, gnome, vscode +- I/O: only firefox is actively using + +1.2 I used `htop` for CPU, Memory; `iostat -x 1 5` for I/O info + +1.3 +``` +sudo find /var -type f -exec du -h {} + | sort -rh | head -n 3 +1.1G /var/lib/docker/volumes/pg_data/_data/base/16653/16664 +1.1G /var/lib/docker/volumes/pg_data/_data/base/16653/16659 +1.1G /var/lib/docker/overlay2/.../diff/usr/local/lib/python3.9/site-packages/tensorflow/libtensorflow_cc.so.2 +``` + +1.4 Firefox is present in all three resource categories (CPU, memory, and I/O), while Docker PSQL volumes account for the largest files in /var, indicating containerized database storage is consuming significant disk space. + +1.5 To optimize resource usage, I would either prune unused Docker volumes or relocate PostgreSQL data to a dedicated cloud storage location to free up disk space. + +# 2 + +2.1 https://moodle.innopolis.university/ + +2.2 ![browser check](image-3.png) + +2.3 ![success checks](image-4.png) + +2.4 ![alert settings](image-5.png) + +2.5 As a student I expect moodle to be available at any time. I also expect it to load in 2 seconds. Therefore, if it takes longer than 2 seconds to load, it's considered degraded. If it takes longer than 10 seconds, I receive the notification. + +2.6 The monitoring setup allows to identify resources bottlenecks causes and write automatic tests that verify that your site is available at any given moment. Otherwise, you get notificated. \ No newline at end of file diff --git a/test.txt b/test.txt new file mode 100644 index 00000000..2eec599a --- /dev/null +++ b/test.txt @@ -0,0 +1 @@ +Test content