MariaDB – Create user

Create user have permissions on all tables

GRANT ALL PRIVILEGES ON *.* TO 'user1'@localhost IDENTIFIED BY 'password1';

Create user have permissions on specific table

GRANT ALL PRIVILEGES ON 'yourDB'.* TO 'user1'@localhost;
FLUSH PRIVILEGES;
SHOW GRANTS FOR 'user1'@localhost;

Drop user

DROP USER 'user1'@localhost;

Create user for exporter

CREATE USER 'exporter'@'192.168.1.%' IDENTIFIED BY 'password' WITH MAX_USER_CONNECTIONS 3;

GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

https://phoenixnap.com/kb/how-to-create-mariadb-user-grant-privileges

Laravel – Queue’ parameter

Redis

In your config/queue.php configuration file, each queue connection defines a retry_after option. This option specifies how many seconds the queue connection should wait before retrying a job that is being processed. For example, if the value of retry_after is set to 90, the job will be released back onto the queue if it has been processing for 90 seconds without being released or deleted. Typically, you should set the retry_after value to the maximum number of seconds your jobs should reasonably take to complete processing.

retry_after

My infrastructure network

Về cơ bản infrastructure network này mình build chưa được hoàn thiện, nhưng cũng thấy tương đối happy về nó. 1 chút chia sẽ.

Router 3910

  • Mình có tổng cộng 4 WANs. Tuy nhiên thực tế chỉ có 1 WAN chính với IP tĩnh

Core Switch – CnMatrix 2028-P

  • Thật ra em này có 1 điểm dở là không có port 2.5Gbe nên vướng 1 con Asus AX86U đành phải xài tạm port 1Gbe
  • 1 port SFP+ đến “Workstation”
  • 1 port 1Gbe đến X300
  • 1 port 1Gbe đến ProDesk
  • 1 port 1Gbe đến Asus AX86U

ProDesk

  • Em nó tuy nhỏ bé nhưng lại gần như là mấu chốt chính của toàn bộ Network. Gọi em nó là gatekeeper
  • HAProxy
    • Tiếp nhận 100% mọi requests và sau đó forwarding đến các server phía sau
    • Cũng là em SSH Jumper luôn
    • Tuy nhiên 1 số bất cập mình chưa làm được
      • Forward RDP
      • Passthrough SSL ( cái này đúng ra đã từng làm được mà giờ lại bị stucked )
  • Grafana
  • Loki
  • Syslog
  • Pihole

Asrock X300

  • Bản chất em này … ăn điện ít mà specs cũng kha khá ( 5700G / 64GB RAM & 2 TB SSD ) nên “hiểu” em nó như 1 thiết bị thứ sẽ online gần như 24/7. Do đó các “services” hosting trên đây là các services cần online liên tục
  • 1 con Virtualmin để hosting … chính các web này và n web khác
  • và 1 vài VM khác

Workstation

  • Em nó chính thức đã được triển khai với ESXi 7
  • 1 em VM “SMB” được attach với các HDDs. Em này bản thân cũng khá nhỏ, chủ yếu để phục vụ SMB / Plex & Torrent thôi
  • Em Workstation ngốn điện cao nên lý thuyết cũng khó online 24/7 mà sẽ có lúc down. Tuy nhiên specs em nó mạnh. Nên các service cần resource cao sẽ nằm trên đây.

ESXi – Github Runners via Docker

Context của bài toán này là build 1 con Docker để chạy Github Runners ( scaleble ). Và mọi thứ được chạy trong 1 con VM thuộc về ESXi

  • ESXi build 1 con VMWare chạy Ubuntu Server 20.04 . Cái này dễ dàng không có gì bàn cãi
  • Và tất nhiên sau đó sẽ setup Docker ( không cần chạy without sudo cũng được )

Và ta có 1 file docker-compose sau

version: "3.7"

services:
  runner:
    image: myoung34/github-runner:latest
    restart: always
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      RUNNER_SCOPE: repo
      RUNNER_NAME_PREFIX: runner
      LABELS: ubuntu,x64
      REPO_URL: <repository_url>
      EPHEMERAL: 1
      ACCESS_TOKEN: <github_token>
    deploy:
      replicas: 4
      resources:
        limits: // Giới hạn tối đa
          cpus: '1'
          memory: 2G
        reservations: // Tối thiểu
          cpus: '1'
          memory: 1G

Và giờ chỉ cần chạy docker-compose up -d

Tuy nhiên câu chuyện chưa hết vui !!! Do bản chất ta đang chạy qua Docker. Do đó việc build các service ( cũng qua docker ) lại không khả thi. Cụ thể là ta cần build MySQL / Redis etc … Vậy thì sao ???

…. tách em nó ra 1 VM khác và update lại IP về con VM đó thôi 😀 . Chút mất công nhưng cơ bản đã dễ dàng rất nhiều.

Từ giờ con VM chạy Runners ta tạo n folder, mỗi folder cho 1 docker-compose ứng với 1 repository

Template Method

Template Method là một design pattern trong đó một khuôn mẫu được định nghĩa, chứa một số bước cơ bản của một thuật toán, trong khi các bước cụ thể được định nghĩa bởi các lớp con. Khuôn mẫu này đảm bảo rằng các bước cơ bản của thuật toán được thực hiện theo cùng một cách, nhưng cách thức cụ thể của từng bước có thể được thay đổi bởi các lớp con.

abstract class Report {
    public function generate() {
        $this->setData();
        $this->formatData();
        $this->generateOutput();
    }
    
    abstract protected function setData();
    
    protected function formatData() {
        // default implementation
    }
    
    abstract protected function generateOutput();
}

class PdfReport extends Report {
    protected function setData() {
        // set data for pdf report
    }
    
    protected function generateOutput() {
        // generate pdf output
    }
}

class ExcelReport extends Report {
    protected function setData() {
        // set data for excel report
    }
    
    protected function generateOutput() {
        // generate excel output
    }
}

Trong đoạn code này, Report là một abstract class định nghĩa khuôn mẫu cho việc tạo ra báo cáo. Phương thức generate() định nghĩa các bước cơ bản trong việc tạo ra báo cáo, bao gồm setData(), formatData()generateOutput(). Trong đó, setData()generateOutput() là các phương thức trừu tượng và phải được định nghĩa bởi các lớp con. Trong khi đó, formatData() có một implementation mặc định, nhưng có thể được ghi đè bởi các lớp con nếu cần thiết.

Các lớp con, như PdfReportExcelReport, kế thừa từ Report và định nghĩa các phương thức trừu tượng để thực hiện các bước cụ thể trong việc tạo ra báo cáo. Ví dụ, PdfReport định nghĩa setData() để thiết lập dữ liệu cho báo cáo PDF, và generateOutput() để tạo ra đầu ra PDF. Tương tự, ExcelReport định nghĩa setData()generateOutput() để tạo ra báo cáo Excel.

Khi chúng ta muốn tạo ra một báo cáo, chúng ta có thể tạo một đối tượng của lớp con và gọi phương thức generate(). Phương thức này sẽ thực hiện các bước cơ bản của thuật toán và gọi các phương thức cụ thể của lớp con để thực hiện các bước cụ

SOLID

SOLID là một nguyên tắc lập trình hướng đối tượng được đặt tên theo chữ cái đầu của các từ trong các nguyên tắc này: Single Responsibility Principle (SRP), Open/Closed Principle (OCP), Liskov Substitution Principle (LSP), Interface Segregation Principle (ISP), và Dependency Inversion Principle (DIP).

Các nguyên tắc SOLID đề cao việc thiết kế các lớp và đối tượng trong hệ thống phần mềm, nhằm tăng tính linh hoạt, dễ bảo trì, mở rộng và tái sử dụng của hệ thống.

Dưới đây là một số định nghĩa cho từng nguyên tắc SOLID:

  1. Single Responsibility Principle (SRP): Một lớp nên chỉ có một trách nhiệm duy nhất và không nên bị phân tán với nhiều trách nhiệm khác.
  2. Open/Closed Principle (OCP): Một lớp nên được thiết kế để dễ dàng mở rộng mà không cần sửa đổi mã nguồn hiện tại.
  3. Liskov Substitution Principle (LSP): Các lớp con phải có thể thay thế được cho các lớp cha của chúng mà không làm thay đổi tính năng của hệ thống.
  4. Interface Segregation Principle (ISP): Các giao diện nên được thiết kế theo những chức năng cụ thể và không nên yêu cầu các phương thức không cần thiết.
  5. Dependency Inversion Principle (DIP): Mã nguồn nên phụ thuộc vào các giao diện và không phải các lớp cụ thể, để tạo tính linh hoạt và dễ bảo trì.

1 chút mở rộng với Interface Segregation Principle

interface PaymentGatewayInterface {
    public function processPayment(float $amount, string $paymentMethod): bool;
    public function refundPayment(float $amount, string $paymentMethod): bool;
    public function savePaymentInfo(array $paymentInfo): bool;
}

Trong ví dụ này, PaymentGatewayInterface định nghĩa các phương thức không cần thiết như refundPayment() và savePaymentInfo(). Nếu PaymentGateway không sử dụng chúng, nó vẫn phải triển khai các phương thức này và sẽ phụ thuộc vào chúng. Việc này có thể dẫn đến các vấn đề về độ phức tạp và hiệu suất của ứng dụng, đồng thời cũng làm cho việc thay đổi PaymentGateway khó khăn hơn nếu chúng ta muốn loại bỏ các phương thức không cần thi

Còn đối với Dependency Inversion Principle (DIP) là một trong những nguyên tắc trong SOLID và nhấn mạnh rằng “Các module cấp cao không nên phụ thuộc vào các module cấp thấp. Cả hai nên phụ thuộc vào abstraction”. Nguyên tắc này khuyến khích chúng ta thiết kế các module để chúng phụ thuộc vào abstraction chung hơn là phụ thuộc vào các chi tiết cụ thể.

DIP có thể được áp dụng bằng cách sử dụng các design pattern như Dependency Injection (DI), Inversion of Control (IoC) và Service Locator.

Ví dụ, giả sử bạn đang phát triển một ứng dụng quản lý đơn hàng. Trong ứng dụng của bạn, bạn có một lớp OrderService để xử lý các thao tác liên quan đến đơn hàng, ví dụ như tạo đơn hàng, cập nhật đơn hàng, hoàn tất đơn hàng, v.v.

Trong trường hợp này, nếu OrderService phụ thuộc vào các lớp cấp thấp như OrderRepository, ProductRepository và CustomerRepository, nó sẽ phải biết chi tiết cụ thể của các lớp này, gây ra sự phụ thuộc chặt chẽ và làm cho việc bảo trì, mở rộng và thay đổi khó khăn hơn.

Thay vào đó, nếu chúng ta áp dụng DIP, chúng ta sẽ tạo ra các abstraction (interface hoặc abstract class) để mô tả các chức năng của các lớp cấp thấp như OrderRepository, ProductRepository và CustomerRepository. Sau đó, chúng ta sẽ thiết kế OrderService để phụ thuộc vào các abstraction này thay vì các lớp cụ thể. Ví dụ:

interface OrderRepositoryInterface {
    public function createOrder(array $orderData): int;
    public function updateOrder(int $orderId, array $orderData): bool;
    public function completeOrder(int $orderId): bool;
}

interface ProductRepositoryInterface {
    public function getProductById(int $productId): array;
}

interface CustomerRepositoryInterface {
    public function getCustomerById(int $customerId): array;
}

class OrderService {
    private $orderRepository;
    private $productRepository;
    private $customerRepository;

    public function __construct(OrderRepositoryInterface $orderRepository, ProductRepositoryInterface $productRepository, CustomerRepositoryInterface $customerRepository) {
        $this->orderRepository = $orderRepository;
        $this->productRepository = $productRepository;
        $this->customerRepository = $customerRepository;
    }

    public function createOrder(array $orderData): int {
        // Use the injected order repository to create the order
        $orderId = $this->orderRepository->createOrder($orderData);

        // Use the injected product repository to get the product information
        $product = $this->productRepository->getProductById($orderData['product_id']);

        // Use the injected customer repository to get the customer information
        $customer = $this->customerRepository->getCustomer

Facade vs Helper trong Laravel

Facade

  • Là một tập hợp các static methods cung cấp cách gọi dễ dàng đến các đối tượng không phải là tĩnh (như các class của Service Container).
  • Facade cung cấp một cách tiếp cận rất thuận tiện cho các đối tượng Laravel, vì nó cho phép bạn gọi các phương thức như bạn đang gọi tới một static methods, mặc dù thực tế là các phương thức được đóng gói trong Service Container.
  • Ví dụ, khi bạn gọi phương thức DB::table('table_name')->get(), thực tế bạn đang gọi đến phương thức get() của đối tượng DB, được quản lý bởi Service Container.

Helper

  • Là một tập hợp các hàm toàn cục (global) được định nghĩa để thực hiện các tác vụ phổ biến, và được sử dụng trong toàn bộ ứng dụng Laravel.
  • Helper không liên quan đến Service Container, và không cung cấp các phương thức cho các đối tượng không phải là tĩnh.
  • Ví dụ, route() là một helper để tạo URL của một route được định nghĩa trong ứng dụng Laravel.

Bất cập của Facade

Giả sử bạn có một ứng dụng Laravel đơn giản, nơi bạn cần thực hiện một số thao tác với đối tượng Request của Laravel. Bạn muốn lấy giá trị của một tham số trong URL và hiển thị nó trên trang web.

Một cách để thực hiện điều này là sử dụng Facade của Laravel, đó là Illuminate\Support\Facades\Request. Bằng cách sử dụng Facade này, bạn có thể lấy giá trị của một tham số bằng cách gọi phương thức input() trên Facade, như sau:

$value = Request::input('parameter');

Tuy nhiên, điều gì sẽ xảy ra nếu Request không được đăng ký trong Service Container của Laravel hoặc không có đối tượng Request nào được trả về từ Service Container? Trong trường hợp này, việc gọi Request::input('parameter') sẽ dẫn đến lỗi runtime, vì Facade không thể truy cập đối tượng Request và sử dụng phương thức input().

Điều này có thể xảy ra nếu bạn đang thực hiện một chức năng đơn giản như hiển thị trang web, nhưng vấn đề sẽ trở nên nghiêm trọng hơn nếu bạn đang phát triển một ứng dụng lớn hơn với nhiều phương thức và đối tượng phức tạp. Việc sử dụng quá nhiều Facade trong trường hợp này có thể dẫn đến mã khó bảo trì và khó hiểu, đặc biệt là khi bạn phải theo dõi nhiều phương thức và đối tượng phức tạp.