🔵 عنوان مقاله
Making Games in Go: 3 Months Without LLMs vs 3 Days With LLMs
🟢 خلاصه مقاله:
**این مقاله روایت شخصی و سرگرمکنندهای از ساخت دو بازی کارتی با زبان Go است که دو رویکرد را مقایسه میکند: بدون کمک LLMها حدود سه ماه زمان برد، اما با کمک LLMها ظرف سه روز به نتیجه رسید. نویسنده نشان میدهد که بخش عمده زمان بدون LLM صرف مطالعه مستندات، اتصال کتابخانهها و رفع خطاها میشود، در حالیکه LLMها با تولید اسکلت کد، خلاصهسازی اسناد و پیشنهاد راهحلها، کارهای زمانبر را فشرده میکنند. نتیجهگیری مقاله این است که LLMها جایگزین مهارت مهندسی نیستند، اما با نظارت و آزمون مناسب میتوانند مسیر رسیدن از ایده به نمونهٔ قابل اجرا را بهطور چشمگیری کوتاه کنند، و Go بستر ساده و محکمی برای این کار فراهم میکند.
🟣لینک مقاله:
https://golangweekly.com/link/173648/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Making Games in Go: 3 Months Without LLMs vs 3 Days With LLMs
🟢 خلاصه مقاله:
**این مقاله روایت شخصی و سرگرمکنندهای از ساخت دو بازی کارتی با زبان Go است که دو رویکرد را مقایسه میکند: بدون کمک LLMها حدود سه ماه زمان برد، اما با کمک LLMها ظرف سه روز به نتیجه رسید. نویسنده نشان میدهد که بخش عمده زمان بدون LLM صرف مطالعه مستندات، اتصال کتابخانهها و رفع خطاها میشود، در حالیکه LLMها با تولید اسکلت کد، خلاصهسازی اسناد و پیشنهاد راهحلها، کارهای زمانبر را فشرده میکنند. نتیجهگیری مقاله این است که LLMها جایگزین مهارت مهندسی نیستند، اما با نظارت و آزمون مناسب میتوانند مسیر رسیدن از ایده به نمونهٔ قابل اجرا را بهطور چشمگیری کوتاه کنند، و Go بستر ساده و محکمی برای این کار فراهم میکند.
🟣لینک مقاله:
https://golangweekly.com/link/173648/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Forwarded from DevOps Labdon
امنیت در Docker: چیزی که اغلب فراموش میکنیم!
* از rootless containers استفاده کنید: اجرای اپلیکیشن با کاربر non-root ریسک نفوذ رو خیلی کم میکنه.
* از Base image سبک و امن استفاده کنید: مثلاً alpine یا distroless. imageهای بزرگتر مثل ubuntu اغلب پکیجهای غیرضروری دارن که سطح حمله رو زیاد میکنن.
* حتما وDependencyها رو pin کنید: همیشه نسخه دقیق کتابخونهها رو مشخص کنید تا از تغییرات ناخواسته جلوگیری بشه.
* از .dockerignore استفاده کنید: فایلهای حساس (مثل .env یا کلیدها) هرگز نباید داخل image قرار بگیرن.
* بهروز نگه داشتن imageها: آسیبپذیریها خیلی سریع پیدا میشن، پس آپدیت مرتب imageها ضروریه.
بارها پیش میاد که به خاطر استفاده از یک base image قدیمی، vulnerability جدی توی اسکن امنیتی پیدا میشه. فقط با عوض کردن base image به نسخهی جدیدتر و سبکتر، هم امنیت بیشتر میشه، هم حجم image کاهش پیدا میکنه.
نکات تکمیلی امنیت در Docker
1. استفاده از Healthcheck
- توی Dockerfile با HEALTHCHECK وضعیت سرویس رو بررسی کنید که باعث میشه container ناسالم زودتر شناسایی و جایگزین بشن.
2. حداقل کردن Surface Attack با distroless images
- این imageها فقط باینری نهایی رو دارن (بدون package manager یا shell).
- دسترسی مهاجم به شدت محدود میشه.
3.فعال کردن User namespace remapping
- باعث میشه کاربر root داخل container، روی سیستم میزبان واقعاً root نباشه.
4. استفاده از Read-Only Filesystem
- container رو با --read-only بالا بیارید تا کسی نتونه فایلهای سیستمی داخلش رو تغییر بده.
5. مدیریت Secretها بهدرستی
- هرگز secrets رو داخل image نذارید.
- از ابزارهایی مثل Docker secrets، HashiCorp Vault یا AWS/GCP Secret Manager استفاده کنید.
6. Scan امنیتی منظم
- ابزارهایی مثل Trivy, Grype یا Docker Scout رو برای اسکن image استفاده کنید.
- این ابزارها آسیبپذیریهای شناختهشده (CVE) رو شناسایی میکنن.
7. محدود کردن Resourceها
- با --cpus و --memory منابع container رو محدود کنید تا جلوی حملات DoS یا مصرف بیرویه گرفته بشه.
8. استفاده از شبکههای ایزوله
- کانتینرهایی که لازم نیست با اینترنت یا کانتینرهای دیگه در ارتباط باشن رو توی یک شبکهی جداگانه نگه دارید.
9. امضای دیجیتال و اعتبارسنجی Imageها
- با Docker Content Trust (DCT) یا cosign امضا و اعتبارسنجی کنید که image تغییر نکرده باشه.
10. بروزرسانی مرتب Docker Engine و Runtime
- چون آسیبپذیریها فقط توی imageها نیستن، بلکه خود daemon و runtime هم میتونه مشکل امنیتی داشته باشه.
*امنیت در Docker فقط به Dockerfile محدود نیست؛ از انتخاب base image شروع میشه، به مدیریت secret و network میرسه و حتی شامل CI/CD pipeline هم میشه*
<Somaye Omidi/>
* از rootless containers استفاده کنید: اجرای اپلیکیشن با کاربر non-root ریسک نفوذ رو خیلی کم میکنه.
* از Base image سبک و امن استفاده کنید: مثلاً alpine یا distroless. imageهای بزرگتر مثل ubuntu اغلب پکیجهای غیرضروری دارن که سطح حمله رو زیاد میکنن.
* حتما وDependencyها رو pin کنید: همیشه نسخه دقیق کتابخونهها رو مشخص کنید تا از تغییرات ناخواسته جلوگیری بشه.
* از .dockerignore استفاده کنید: فایلهای حساس (مثل .env یا کلیدها) هرگز نباید داخل image قرار بگیرن.
* بهروز نگه داشتن imageها: آسیبپذیریها خیلی سریع پیدا میشن، پس آپدیت مرتب imageها ضروریه.
بارها پیش میاد که به خاطر استفاده از یک base image قدیمی، vulnerability جدی توی اسکن امنیتی پیدا میشه. فقط با عوض کردن base image به نسخهی جدیدتر و سبکتر، هم امنیت بیشتر میشه، هم حجم image کاهش پیدا میکنه.
نکات تکمیلی امنیت در Docker
1. استفاده از Healthcheck
- توی Dockerfile با HEALTHCHECK وضعیت سرویس رو بررسی کنید که باعث میشه container ناسالم زودتر شناسایی و جایگزین بشن.
2. حداقل کردن Surface Attack با distroless images
- این imageها فقط باینری نهایی رو دارن (بدون package manager یا shell).
- دسترسی مهاجم به شدت محدود میشه.
3.فعال کردن User namespace remapping
- باعث میشه کاربر root داخل container، روی سیستم میزبان واقعاً root نباشه.
4. استفاده از Read-Only Filesystem
- container رو با --read-only بالا بیارید تا کسی نتونه فایلهای سیستمی داخلش رو تغییر بده.
5. مدیریت Secretها بهدرستی
- هرگز secrets رو داخل image نذارید.
- از ابزارهایی مثل Docker secrets، HashiCorp Vault یا AWS/GCP Secret Manager استفاده کنید.
6. Scan امنیتی منظم
- ابزارهایی مثل Trivy, Grype یا Docker Scout رو برای اسکن image استفاده کنید.
- این ابزارها آسیبپذیریهای شناختهشده (CVE) رو شناسایی میکنن.
7. محدود کردن Resourceها
- با --cpus و --memory منابع container رو محدود کنید تا جلوی حملات DoS یا مصرف بیرویه گرفته بشه.
8. استفاده از شبکههای ایزوله
- کانتینرهایی که لازم نیست با اینترنت یا کانتینرهای دیگه در ارتباط باشن رو توی یک شبکهی جداگانه نگه دارید.
9. امضای دیجیتال و اعتبارسنجی Imageها
- با Docker Content Trust (DCT) یا cosign امضا و اعتبارسنجی کنید که image تغییر نکرده باشه.
10. بروزرسانی مرتب Docker Engine و Runtime
- چون آسیبپذیریها فقط توی imageها نیستن، بلکه خود daemon و runtime هم میتونه مشکل امنیتی داشته باشه.
*امنیت در Docker فقط به Dockerfile محدود نیست؛ از انتخاب base image شروع میشه، به مدیریت secret و network میرسه و حتی شامل CI/CD pipeline هم میشه*
<Somaye Omidi/>
❤3
🔵 عنوان مقاله
How to Deploy a Hugo Static Site to Hetzner
🟢 خلاصه مقاله:
یک راهنمای مرحلهبهمرحله برای استقرار سایت استاتیک Hugo روی Hetzнер است که با تکیه بر سادگی، هزینه کم و کارایی بالا، دو مسیر اصلی را توضیح میدهد: میزبانی روی یک سرور ابری سبک (با Nginx/Caddy) یا استفاده از سرویسهای ذخیرهسازی برای حذف نگهداری سرور. سپس یک خط لولهٔ خودکار پیشنهاد میکند که با هر push کد، سایت را میسازد و با ابزارهایی مثل rsync/scp/rclone منتشر میکند، همراه با مدیریت امن کلیدها، استقرار اتمیک و امکان rollback. در ادامه تنظیم DNS و TLS (Let’s Encrypt)، هدرهای کش، فشردهسازی، و در صورت نیاز CDN پوشش داده میشود. خروجی، فرآیندی تکرارپذیر از گیت تا تولید است که HTTPS، کارایی مناسب و نگهداری کمهزینه را روی Hetzner فراهم میکند.
🟣لینک مقاله:
https://golangweekly.com/link/173631/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
How to Deploy a Hugo Static Site to Hetzner
🟢 خلاصه مقاله:
یک راهنمای مرحلهبهمرحله برای استقرار سایت استاتیک Hugo روی Hetzнер است که با تکیه بر سادگی، هزینه کم و کارایی بالا، دو مسیر اصلی را توضیح میدهد: میزبانی روی یک سرور ابری سبک (با Nginx/Caddy) یا استفاده از سرویسهای ذخیرهسازی برای حذف نگهداری سرور. سپس یک خط لولهٔ خودکار پیشنهاد میکند که با هر push کد، سایت را میسازد و با ابزارهایی مثل rsync/scp/rclone منتشر میکند، همراه با مدیریت امن کلیدها، استقرار اتمیک و امکان rollback. در ادامه تنظیم DNS و TLS (Let’s Encrypt)، هدرهای کش، فشردهسازی، و در صورت نیاز CDN پوشش داده میشود. خروجی، فرآیندی تکرارپذیر از گیت تا تولید است که HTTPS، کارایی مناسب و نگهداری کمهزینه را روی Hetzner فراهم میکند.
🟣لینک مقاله:
https://golangweekly.com/link/173631/web
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Pliutau
Deploy Hugo static site to Hetzner
Recently I ditched my AWS account and moved my personal small projects to a Hetzner VPS, what a nice feeling tinkering with your own server again! As a part of this process I also had to change how I deploy this blog, so I thought I would share my setup in…
🔥1