#127 - Server Docker bị mã độc đào tiền ảo tấn công

Jun 28, 2020

Những bài viết hay

Case study: Analyzing Notion app performance — 3perf.com

Tối ưu hoá, tăng tốc web app luôn là một trong những chủ đề hấp dẫn dành cho các Frontend Engineers. Trong bài viết, tác giả Ivan Akulov đã chia sẻ những cách mà anh ấy đã thử reverse-engineer Notion App (một ứng dụng quản lí note - build trên React.js), sử dụng WebPageTest để analyze/benchmark và optimize các thành phần để có được kết quả tăng tốc độ load của app lên 30%: lazy load các thành phần chưa cần thiết, chia tách code, loại bỏ polyfills và các vendor code không sử dụng, pre-load API data, sử dụng Cache-Control, thêm hiệu ứng loading skeleton ...

Data Warehousing: Basics of Relational Vs Star Schema Data Modeling — medium.com

Relational database schema là một trong những schema lâu đời và phổ biến trong hệ thống quản lý cơ sở dữ liệu. Thường thì schema này sẽ được tối ưu hóa để đạt được:

Minimal data redundancy: hạn chế dữ liệu được nhân rộng ở nhiều nơi
Fast read/write: tối ưu hóa để việc viết và đọc dữ liệu một cách nhanh chóng
Current data only: chỉ chứa dữ liệu hiện tại của hệ thống

Do đó, để đạt được hiệu quả cao cho việc phân tích dữ liệu ở data warehouse, star schema đã được thiết kế ra nhằm mục đích cho việc chứa dữ liệu với những yếu tố sau:

Redundant data storage for performance: dữ liệu có thể được lập lại ở bảng chứa dữ liệu để tăng hiệu suất
Fast reads only: chỉ tối ưu hóa để đọc dữ liệu
Current & historical data: chứa dữ liệu hiện tại và lịch sử của những bảng dữ liệu

Bài viết sau đây sẽ được tác giả nói cụ thể hơn về những lợi ích và hạn chế của việc sử dụng star schema ở data warehouse so với việc sử dụng relational schema phổ biến hiện nay.

Saga Pattern, Application Transactions Using Microservices — blog.couchbase.com

Database transaction là một phần quan trọng trong bất kì hệ thống nào. Two-Phase Commit được sử dụng để giải quyết bài toán các transaction phụ thuộc lẫn nhau. Ví dụ, trong tính năng đặt hàng, để xác nhận một đơn hàng chúng ta cần làm 2 bước (transaction): cập nhật trạng thái đơn hàng và cập nhật số lượng còn lại của sản phẩm. Bước cập nhật trạng thái đơn hàng hoàn tất khi và chỉ khi bước cập nhật số lượng hoàn tất.

Tuy nhiên vấn đề trở nên rất phức tạp trong kiến trúc microservices, khi mà mỗi service có một database riêng. Việc áp dụng Two-Phase Commit là bất khả thi. Một trong những giải pháp cho bài toán này là SAGA pattern được thiệu lần đầu vào năm 1987.

Có nhiều cách để xây dựng SAGA pattern, trong đó 2 cách phổ biến:

Events/Choreography: các services tạo event (publish) khi hoàn tất một tác vụ của mình và lắng nghe event của các services khác (subscribe) để quyết định có thực hiện một hành động tương ứng hay không.
Command/Orchestration: xây dựng một service hoạt động như một điều phối viên chịu trách nhiệm nói cho các service khác làm tác vụ gì và khi nào làm tác vụ đó.

Mỗi một cách đều có ưu và nhược điểm riêng. Bài viết sau tác giả sẽ trình bày chi tiết hơn về SAGA pattern trong một bài toán thực tiễn E-commerce.

Kubernetes Patterns : The Init Container Pattern — www.magalix.com

Thiết kế khởi tạo (Initialization Pattern) là một vấn đề phổ biến của nhiều ngôn ngữ khác nhau. Trong lập trình hướng đối tượng, chúng ta sử dụng “constructor”. Contructor được gọi mỗi khi 1 object được khởi tạo. Mục đích của constructor là trang bị những yếu tố cần thiết để object có thể thực thi được các công việc cần làm, ví dụ như tạo giá trị mặc định cho các biến, tạo kết nối đến cơ sở dữ liệu, ....

Mục đích của thiết kế khởi tạo là để tách biệt một object khỏi logic khởi tạo của nó. Vì vậy, nếu 1 object phụ thuộc vào dữ liệu được truy vấn từ một database, việc này nên được thực thi trong constructor. Điều này giúp ta dễ dàng thay đổi cách object khởi tạo mà không ảnh hưởng đến cách object hoạt động.

Kubernetes sử dụng mô hình này 1 cách tưởng tự. Nếu trong lập trình hướng đối tượng, object được coi là đơn vị cốt lõi, thì trong Kubernetes, đó là Pod. Vậy nên, nếu một một ứng dụng chạy trong một container cần có logic để khởi tạo, logic này nên được thực hiện trong 1 container khác. Kubernetes cung cấp một loại container để thực hiện việc này, đó là init container.

Một số đặc điểm của init container trong Kubernestes:

Chúng luôn được chạy trước các container khác trong 1 Pod. Vậy nên, chúng nên nhỏ gọn và không chứa các logic phức tạp cần nhiều thời gian để xử lý.
Các init containers được chạy theo tình tự. Một init container sẽ được bắt đầu chỉ khi init container trước đó kết thúc thành công. Vì vậy nếu logic khởi tạo quá phức tạp, chúng ta nên chia nhỏ thành các việc nhỏ hơn, mỗi việc chạy trên 1 init container. Việc này giúp chúng ta dễ dàng xác định init container nào các vấn đề khi có lỗi khởi tạo xảy ra.
Nếu bất cứ một init container nào có lỗi, toàn bộ Pod sẽ bị khởi động lại (trừ khi chúng ta điều chỉnh restartPolicy thành 'Never'). Điều này có nghĩa, toàn bộ init containers sẽ được chạy lại. Vì vậy, ta cần đảm bảo logic khởi tạo có thể chạy nhiều lần mà không tạo ra trùng lặp.
Một init container giúp ích việc trì hoãn ứng dụng bắt đầu trừ khi toàn bộ dependencies của nó thoả mãn. Thay vì sử dụng health hay readiness probes cho việc này, sử dụng init container sẽ đơn giản hơn trong nhiều trường hợp.
Init containers không thể sử dụng health hay readiness probes.
Tất cả containers trong cùng 1 Pod chia sẻ chung Volumes và network. Chúng ta có thể tận dụng điều này để chia sẽ dữ liệu giữa ứng dụng và các init containers.

Góc Database

Khi làm việc với các hệ thống Relational Database, ắt hẳn bạn sẽ dành nhiều thời gian để tối ưu câu query của mình, đặc biệt là các phép Join. Nên join trái hay join phải, nên để bản nào join trước bảng nào join sau, ... là những câu hỏi mà bạn cần phải trả lời. Trong video dưới đây, bạn sẽ được ôn lại những kiến thức nền tảng về cách phép Join vận hành cũng những loại tối ưu cần thiết liên quan, thông qua đó, hy vọng bạn sẽ có nền tảng tốt hơn đểu hiểu và tối ưu câu query của mình.

Code & Tools

Tin tức khác

Server Docker bị mã độc đào tiền ảo tấn công — whitehat.vn

Mới đây, các chuyên an ninh mạng đã phát hiện các hacker đã tạo ra các Docker Image nhằm mục đích đào tiền ảo và được phát tán thông qua Docker Container và Docker Hub.

Sau đó, các máy tính bị nhiễm sẽ bị chiếm tài nguyên và chạy các thuật toán đào tiền ảo.

Được biết, các Image được lưu trữ trên tài khoản đã đào tiền ảo hơn 2 triệu lần kể từ tháng 10 năm 2019, một trong những ID của ví kiếm được hơn 525,38 XMR (36.000 đô la).

Quotes

Experience is the name everyone gives to their mistakes.

- Oscar Wilde