Hướng dẫn thực hành: Passkeys, Docker Compose Watch, Ollama và GitHub Copilot Cloud Agent

Hướng dẫn công nghệ thực hành hôm nay: Passkeys, Docker Compose Watch, Ollama và GitHub Copilot Cloud Agent

Trích dẫn ảnh: “Programming.jpg”, Wikimedia Commons. Nguồn ảnh: https://commons.wikimedia.org/wiki/File:Programming.jpg. Định dạng sử dụng: JPG, không phải SVG.

Bản hướng dẫn này tập trung vào bốn nhóm công nghệ có giá trị thực tế cao cho người dùng kỹ thuật và lập trình viên: passkeys để giảm phụ thuộc vào mật khẩu, Docker Compose Watch để tăng tốc vòng lặp phát triển, Ollama để chạy mô hình AI cục bộ và GitHub Copilot Cloud Agent để giao tác vụ lập trình theo nhánh/pull request. Nội dung ưu tiên cách áp dụng, checklist triển khai và nguồn tham khảo chính thức.

Tóm tắt nhanh

Passkeys phù hợp khi bạn muốn đăng nhập an toàn hơn mật khẩu, giảm rủi ro phishing và tận dụng xác thực bằng sinh trắc học hoặc mã PIN của thiết bị. Docker Compose Watch phù hợp cho dự án đang phát triển bằng container nhưng cần tự động đồng bộ mã nguồn mà không phải rebuild thủ công liên tục. Ollama phù hợp khi bạn muốn thử nghiệm mô hình AI cục bộ hoặc gọi mô hình qua API nội bộ trên máy. GitHub Copilot Cloud Agent phù hợp khi bạn muốn giao các issue nhỏ, tác vụ refactor, cập nhật tài liệu hoặc tăng test coverage theo quy trình branch và pull request.

Nguồn tham khảo chính: Microsoft Learn về passkeys trên Windows, Google Developers về passkeys trong web app, Docker Docs về Compose Watch, Ollama Docs về API và GitHub Docs về Copilot Cloud Agent.

---

1. Cách bắt đầu với passkeys để giảm phụ thuộc vào mật khẩu

Trích dẫn ảnh: “SecureID token new.JPG”, Wikimedia Commons. Nguồn ảnh: https://commons.wikimedia.org/wiki/File:SecureID_token_new.JPG. Định dạng sử dụng: JPG, không phải SVG.

Passkeys giải quyết vấn đề gì?

Passkeys là phương thức đăng nhập dùng cặp khóa công khai/khóa riêng thay cho mật khẩu truyền thống. Khóa riêng được lưu trên thiết bị hoặc trình quản lý thông tin xác thực, còn dịch vụ chỉ lưu khóa công khai. Khi đăng nhập, thiết bị ký một thử thách xác thực thay vì gửi mật khẩu qua biểu mẫu. Theo Microsoft Learn, passkeys có thể dùng cơ chế mở khóa thiết bị như Windows Hello, sinh trắc học hoặc PIN; chúng cũng được thiết kế để giảm rủi ro đoán mật khẩu, tái sử dụng mật khẩu và phishing. Nguồn: https://learn.microsoft.com/windows/security/identity-protection/passkeys/.

Google Developers cũng mô tả passkeys như một cách để người dùng đăng nhập website hoặc ứng dụng bằng cơ chế khóa màn hình thiết bị, chẳng hạn vân tay, khuôn mặt hoặc PIN. Khi triển khai trên web, passkey phải được tạo, gắn với tài khoản người dùng và lưu khóa công khai ở phía máy chủ trước khi đăng nhập. Nguồn: https://developers.google.com/codelabs/passkey-form-autofill.

Khi nào nên triển khai passkeys?

Bạn nên ưu tiên passkeys nếu sản phẩm của bạn có một trong các đặc điểm sau: người dùng thường quên mật khẩu, tài khoản có dữ liệu nhạy cảm, hệ thống đang chịu nhiều cuộc tấn công phishing, hoặc bạn muốn giảm chi phí hỗ trợ liên quan đến reset mật khẩu. Passkeys cũng phù hợp với các ứng dụng SaaS, tài khoản khách hàng, cổng quản trị nội bộ và sản phẩm có người dùng đăng nhập thường xuyên trên điện thoại/laptop cá nhân.

Không nên coi passkeys là cách thay thế toàn bộ chính sách bảo mật trong một lần. Với hệ thống đang vận hành, nên triển khai theo lộ trình: cho phép người dùng thêm passkey trong trang bảo mật tài khoản, giữ mật khẩu hoặc phương thức khôi phục trong giai đoạn chuyển tiếp, ghi log các sự kiện thêm/xóa passkey và chuẩn bị quy trình hỗ trợ khi người dùng mất thiết bị.

Checklist triển khai cho website

Bước đầu tiên là kiểm tra trình duyệt và nền tảng mục tiêu có hỗ trợ WebAuthn/passkeys hay không. Với web app, bạn cần luồng đăng ký passkey, luồng đăng nhập bằng passkey, cơ chế đặt tên thiết bị để người dùng dễ quản lý và màn hình thu hồi passkey khi cần.

Ở phía backend, bạn cần lưu public key, credential ID, thông tin người dùng, bộ đếm hoặc thông tin xác thực cần thiết tùy thư viện triển khai. Tuyệt đối không tự thiết kế thuật toán mật mã nếu không có chuyên môn; nên dùng thư viện WebAuthn uy tín theo ngôn ngữ backend của bạn.

Ở phía UX, nút “Đăng nhập bằng passkey” nên xuất hiện ở màn hình đăng nhập và trang bảo mật tài khoản. Thông báo cần giải thích đơn giản: người dùng không gửi mật khẩu cho website; họ dùng thiết bị để xác nhận đăng nhập. Nếu đối tượng người dùng không rành kỹ thuật, nên ghi rõ passkey có thể nằm trong điện thoại, laptop, trình duyệt hoặc trình quản lý mật khẩu.

Lỗi thường gặp

Lỗi phổ biến nhất là triển khai passkeys như một tính năng ẩn trong cài đặt, khiến người dùng không biết để kích hoạt. Lỗi thứ hai là không có quy trình khôi phục khi người dùng mất thiết bị. Lỗi thứ ba là truyền thông sai, khiến người dùng tưởng passkey là “một mật khẩu mới”. Cách viết đúng là: passkey là phương thức đăng nhập không cần gõ mật khẩu, dựa trên khóa mật mã và cơ chế mở khóa thiết bị.

---

2. Cách dùng Docker Compose Watch để tăng tốc phát triển local

Trích dẫn ảnh: “Docker (container engine) logo.png”, Wikimedia Commons. Nguồn ảnh: https://commons.wikimedia.org/wiki/File:Docker_(container_engine)_logo.png. Định dạng sử dụng: PNG, không phải SVG.

Docker Compose Watch là gì?

Docker Compose giúp mô tả nhiều service, network và volume trong một file YAML rồi khởi động toàn bộ stack bằng một lệnh. Nguồn: https://docs.docker.com/compose/.

Compose Watch là cơ chế theo dõi thay đổi file trong môi trường phát triển. Theo Docker Docs, Compose Watch phù hợp với service được build từ mã nguồn local bằng thuộc tính build; nó không theo dõi thay đổi cho service chỉ dùng image dựng sẵn qua thuộc tính image. Nguồn: https://docs.docker.com/compose/how-tos/file-watch/.

Khi nào nên dùng Compose Watch?

Bạn nên dùng Compose Watch khi dự án có frontend, backend hoặc worker chạy trong container và bạn muốn thay đổi mã nguồn trên máy host được phản ánh vào container nhanh hơn. Với dự án JavaScript/TypeScript, Compose Watch hữu ích khi bạn muốn đồng bộ thư mục src, nhưng không muốn đồng bộ node_modules vì vấn đề hiệu năng và khác biệt hệ điều hành/kiến trúc CPU.

Docker Docs lưu ý rằng Watch không thay thế hoàn toàn bind mount. Bind mount vẫn phù hợp khi bạn cần chia sẻ nguyên thư mục vào container, còn Watch phù hợp hơn khi cần quy tắc chi tiết: sync file nào, rebuild khi file nào thay đổi và bỏ qua thư mục nào. Nguồn: https://docs.docker.com/compose/how-tos/file-watch/.

Ví dụ cấu hình cơ bản

services:
  web:
    build: .
    command: npm run dev
    ports:
      - "3000:3000"
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: package.json
        - action: rebuild
          path: package-lock.json

Cấu hình trên đồng bộ thay đổi trong thư mục src vào container, nhưng rebuild image khi package.json hoặc package-lock.json thay đổi. Với dự án Node.js, không nên sync node_modules từ máy host vào container vì package native có thể khác nhau giữa host và container.

Lệnh chạy đề xuất

docker compose watch

Trong một số workflow, bạn có thể dùng:

docker compose up --watch

Trước khi áp dụng cho dự án lớn, hãy chạy thử với một service nhỏ. Kiểm tra xem container có quyền ghi vào target path hay không. Docker Docs lưu ý container cần có các executable phổ biến như stat, mkdir và rmdir, đồng thời user trong container phải có quyền ghi vào đường dẫn đích. Nguồn: https://docs.docker.com/compose/how-tos/file-watch/.

Checklist tối ưu

Không bật watch cho toàn bộ service nếu không cần thiết. Chỉ bật cho service đang phát triển tích cực, thường là frontend hoặc API. Đưa thư mục sinh ra tự động, cache, build output và dependency lớn vào danh sách ignore nếu phù hợp. Tách quy tắc sync và rebuild: mã nguồn thường sync, file cấu hình dependency thường rebuild.

---

3. Cách chạy AI cục bộ bằng Ollama và gọi qua API

Trích dẫn ảnh: “Artificial Intelligence & AI & Machine Learning - 30212411048.jpg”, Wikimedia Commons. Nguồn ảnh: https://commons.wikimedia.org/wiki/File:Artificial_Intelligence_%26_AI_%26_Machine_Learning_-_30212411048.jpg. Định dạng sử dụng: JPG, không phải SVG.

Vì sao nên thử AI cục bộ?

AI cục bộ phù hợp khi bạn muốn thử nghiệm mô hình ngôn ngữ trên máy cá nhân, kiểm soát dữ liệu tốt hơn trong giai đoạn phát triển hoặc xây dựng prototype không phụ thuộc hoàn toàn vào API đám mây. Với Ollama, bạn có thể chạy mô hình và gọi qua API nội bộ. Theo Ollama Docs, API mặc định sau khi cài đặt được phục vụ tại http://localhost:11434/api, và có endpoint như generate, chat, embed, tags, pull, delete. Nguồn: https://docs.ollama.com/api/introduction.

Cài đặt và kiểm tra nhanh

Sau khi cài Ollama theo hệ điều hành, kiểm tra phiên bản:

ollama --version

Tải một mô hình phù hợp với máy của bạn:

ollama pull gemma3

Chạy thử mô hình:

ollama run gemma3

Gọi API bằng curl:

curl http://localhost:11434/api/generate -d '{
  "model": "gemma3",
  "prompt": "Viết checklist bảo mật cơ bản cho một website nhỏ."
}'

Ollama Docs đưa ví dụ gọi endpoint generate bằng curl và cho biết có thư viện chính thức cho Python và JavaScript. Nguồn: https://docs.ollama.com/api/introduction.

Khi tích hợp vào ứng dụng

Với ứng dụng nội bộ, bạn có thể tạo service gọi Ollama API thay vì gọi trực tiếp từ frontend. Cách này giúp kiểm soát prompt, giới hạn dữ liệu gửi vào mô hình và thêm logging. Không nên để endpoint Ollama mở trực tiếp ra Internet nếu chưa có lớp xác thực, rate limit và kiểm soát truy cập.

Ví dụ Node.js tối giản:

const response = await fetch('http://localhost:11434/api/generate', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    model: 'gemma3',
    prompt: 'Tóm tắt nội dung sau thành 5 ý chính: ...',
    stream: false
  })
});

const data = await response.json();
console.log(data.response);

Checklist an toàn dữ liệu

Không đưa secret, private key, access token hoặc dữ liệu khách hàng nhạy cảm vào prompt thử nghiệm. Với máy dùng chung trong công ty, cần xác định rõ mô hình, log và quyền truy cập. Nếu chuyển từ prototype sang production, cần đánh giá chất lượng mô hình, độ trễ, chi phí phần cứng, giám sát lỗi và khả năng rollback sang API khác khi cần.

---

4. Cách giao việc cho GitHub Copilot Cloud Agent theo quy trình pull request

Trích dẫn ảnh: “Colorful code (Unsplash).jpg”, Wikimedia Commons. Nguồn ảnh: https://commons.wikimedia.org/wiki/File:Colorful_code_(Unsplash).jpg. Định dạng sử dụng: JPG, không phải SVG.

Copilot Cloud Agent khác gì chat AI trong IDE?

Theo GitHub Docs, Copilot Cloud Agent có thể nghiên cứu repository, tạo kế hoạch triển khai, sửa mã trên một branch, cho phép bạn xem diff, lặp lại thay đổi và tạo pull request khi sẵn sàng. GitHub cũng mô tả agent này chạy trong môi trường phát triển tạm thời được hỗ trợ bởi GitHub Actions, nơi nó có thể khám phá code, sửa code, chạy test và linter. Nguồn: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent.

Điểm khác biệt quan trọng là Copilot Cloud Agent làm việc theo hướng bất đồng bộ trên GitHub, trong khi agent mode trong IDE thường sửa trực tiếp trong môi trường local của lập trình viên. Vì vậy, Cloud Agent phù hợp với issue rõ ràng, tác vụ nhỏ đến vừa, hoặc việc cần tạo nhánh và PR để review.

Nên giao loại task nào?

Nên giao các task có phạm vi rõ: sửa bug đã mô tả được cách tái hiện, bổ sung unit test, cập nhật README, refactor hàm nhỏ, thêm logging, sửa lỗi lint, cải thiện thông báo lỗi hoặc nâng cấp dependency có phạm vi hẹp. Không nên giao một yêu cầu mơ hồ như “tối ưu toàn bộ hệ thống” nếu không có bối cảnh, tiêu chí nghiệm thu và giới hạn phạm vi.

Prompt mẫu để giao task

Bạn đang làm việc trong repository này. Hãy đọc cấu trúc dự án trước khi sửa code.

Mục tiêu:
- Sửa lỗi [mô tả lỗi cụ thể].
- Giữ nguyên hành vi hiện có ngoài phạm vi lỗi này.
- Thêm hoặc cập nhật test nếu dự án có test framework tương ứng.

Ràng buộc:
- Không đổi public API nếu không cần thiết.
- Không thêm dependency mới nếu có thể giải quyết bằng dependency hiện có.
- Sau khi sửa, chạy lint/test liên quan và ghi rõ kết quả.

Tiêu chí hoàn thành:
- Lỗi được tái hiện hoặc giải thích rõ nếu không tái hiện được.
- Có diff nhỏ, dễ review.
- Có mô tả thay đổi trong PR.

Checklist review PR do AI tạo

Không merge chỉ vì PR build xanh. Cần đọc diff, kiểm tra logic nghiệp vụ, kiểm tra bảo mật, xem test có thật sự bao phủ lỗi hay chỉ kiểm tra hời hợt, và đảm bảo không có thay đổi ngoài phạm vi. Nếu PR đụng đến xác thực, thanh toán, quyền truy cập hoặc dữ liệu người dùng, nên review như code của một lập trình viên mới: kỹ, chậm và có checklist.

GitHub Docs cho biết Cloud Agent có thể xử lý các việc như fix bug, triển khai tính năng nhỏ, cải thiện test coverage, cập nhật tài liệu, xử lý technical debt và resolve merge conflict. Nguồn: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent.

---

Bảng chọn nhanh công nghệ nên áp dụng

FAQ ngắn cho SEO và GEO

Passkeys có thay thế mật khẩu ngay lập tức không?

Không nên thay thế đột ngột với hệ thống đang có người dùng thật. Cách an toàn hơn là cho phép thêm passkey như một phương thức đăng nhập mới, giữ kênh khôi phục tài khoản và theo dõi tỷ lệ sử dụng trước khi ép chuyển đổi.

Docker Compose Watch có thay bind mount không?

Không hoàn toàn. Docker Docs mô tả Watch như một cơ chế bổ trợ cho phát triển trong container, hữu ích khi cần quy tắc đồng bộ chi tiết hơn bind mount.

Ollama có phù hợp cho production không?

Có thể phù hợp cho một số hệ thống nội bộ hoặc deployment được kiểm soát, nhưng cần đánh giá bảo mật, hiệu năng, giám sát, tài nguyên GPU/CPU và quy trình cập nhật mô hình. Không nên mở API local ra Internet nếu chưa có xác thực và kiểm soát truy cập.

Có nên merge code do Copilot Cloud Agent tạo không cần review không?

Không. PR do AI tạo vẫn phải review như PR bình thường. Cần kiểm tra diff, test, phạm vi thay đổi, bảo mật và tác động nghiệp vụ trước khi merge.

Nguồn tham khảo

1. Microsoft Learn — Support for passkeys in Windows: https://learn.microsoft.com/windows/security/identity-protection/passkeys/
2. Google Developers — Implement passkeys with form autofill in a web app: https://developers.google.com/codelabs/passkey-form-autofill
3. Docker Docs — Docker Compose: https://docs.docker.com/compose/
4. Docker Docs — Use Compose Watch: https://docs.docker.com/compose/how-tos/file-watch/
5. Ollama Docs — API Introduction: https://docs.ollama.com/api/introduction
6. GitHub Docs — About GitHub Copilot Cloud Agent: https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent
7. Wikimedia Commons — Programming.jpg: https://commons.wikimedia.org/wiki/File:Programming.jpg
8. Wikimedia Commons — SecureID token new.JPG: https://commons.wikimedia.org/wiki/File:SecureID_token_new.JPG
9. Wikimedia Commons — Docker logo PNG: https://commons.wikimedia.org/wiki/File:Docker_(container_engine)_logo.png
10. Wikimedia Commons — Artificial Intelligence & AI & Machine Learning: https://commons.wikimedia.org/wiki/File:Artificial_Intelligence_%26_AI_%26_Machine_Learning_-_30212411048.jpg
11. Wikimedia Commons — Colorful code (Unsplash).jpg: https://commons.wikimedia.org/wiki/File:Colorful_code_(Unsplash).jpg