Saturday, 27 June 2020

Chạy ứng dụng machine learning trên production


Đi cùng với sự phổ cập AI/ML trong đời sống từng người dân,  khái niệm DevOps cho các ứng dụng Machine Learning, thường gọi MLOps, đang dần hình thành ở giai bước đầu với nhiều công cụ open-source với nhiều đóng góp khá sôi động.

Theo tôi MLOps dựa trên các khái niệm, công cụ sử dụng trong DevOps tuy nhiên có một vài đặc thù  phát triển và vận hành các ứng dụng ML cần có các công cụ được tuỳ biến để phù hợp với việc xây dựng một life cycle cho các ứng dụng ML từ khâu design, development tới chạy production.

Các điểm khác biệt của một ứng dụng ML 

- Data Versioning
- Model Versioning
- GPU, hardware requirements
- Release, Production ML application


Các bài viết, công cụ trên internet liên quan tới MLOps về các công cụ này mà tôi sưu tầm được

- Continuous Delivery for Machine Learning (CD4ML) https://martinfowler.com/articles/cd4ml.html
- What I learned from looking at 200 machine learning tools https://huyenchip.com/2020/06/22/mlops.html




<tiếp tục cập nhật>

Monday, 7 October 2019

Bắt đầu với kỹ thuật sharding trong database

Một trong các bottleneck của hệ thống thường xảy ra ở lớp database. Bạn phát hiện ra hệ thống của mình cũng rơi vào trường hợp tương tụ như vậy, việc đọc và ghi dữ liêu vô database bị chậm với lượng dữ liệu ngày càng lớn. Khi đó bạn phải nghĩ tới việc mở rộng database của mình. 

Một bài viết hay về sharding.
https://medium.com/@jeeyoungk/how-sharding-works-b4dec46b3f6




Khi nói tới việc mở rộng databases có hai xu hướng chính:
 
- mở rộng theo chiều dọc (vertical scaling)
- mở rộng theo chiều ngang (horizontal scaling) 

Mở rộng theo chiều dọc: 
- thực hiện việc tạo thêm nhiều tables và lưu ở các databases riêng biệt. Công việc này thường sẽ thực hiện ở lớp ứng dụng, bạn sẽ cần phải phân chia các ứng dụng của mình, mỗi ứng dụng sẽ sử dụng một database tách biệt. Việc sử dụng micro services cùng với việc mỗi service sử dụng một ngôn ngữ lập trình và một hệ cơ sở dữ liệu khác nhau được xem là một phương thức áp dụng việc mở rộng database theo chiều dọc.

Mở rộng theo chiều ngang: 
- thực hiện lưu trữ các rows của một table ở trên các máy chủ database khác nhau (được gọi là kỹ thuật sharding). Sharding đã được áp dụng ở nhiều hệ cơ sở dữ liệu khác nhau, gần như các hệ cơ sở dữ liệu hiện đại đều đang dùng sharding như là một tính năng hiển nhiên phải có,  ví dụ Cassandra, MongoDB, HBase ... 


Sharding (mở rộng database theo chiều ngang) được sử dụng khi dữ liệu lưu trữ trong một table quá lớn dẫn tới việc lưu trữ các rows của table đó ở nhiều máy chủ khác nhau là cần thiết, nhằm đảm bảo hiệu năng và khả năng mở rộng cho hệ thống. 

Có nhiều phương pháp thực hiện sharding, các phương pháp được phân biệt và so sánh dựa trên: 

- cách dữ liệu được đọc lên từ database (reading data) 
- cách dữ liệu được ghi xuống database (writing data)

Một khái niệm quan trọng trong sharding là Partition Key, nó sẽ xác định việc dữ liệu sẽ được lưu trữ phân tán như thế nào, dựa trên Partition Key để truy cập và chỉnh sửa dữ liệu một cách hiệu quả thông qua việc điều hướng các thao tác với database vô đúng nơi mà dữ liệu đang được lưu. Các dữ liệu có cùng Partition Key sẽ được lưu trên cùng một nơi (máy chủ).


Sharding được phân theo 2 loại chính là Algorithmic và Dynamic. Với Algorithmic sharding thì client sẽ tự xác định được dữ liệu đang được lưu ở đâu, còn đối với Dynamic sharding cần có một locator service để giúp xác định dữ liệu đang được lưu ở đâu.

Algorithmic sharding

Kiểu sharding này sẽ sử dụng một hàm sharding nhận vô tham số partition_key và trả về database_id để xác định vị trí dữ liệu ở đâu. 
Một hàm sharding đơn giản có thể dùng đó là: hash(key) % number_of_db. 

Dữ liệu được lưu trữ phân tán chỉ dựa trên hàm sharding, không phụ thuộc vào độ lớn dữ liệu hay không gian lưu trữ. Do đó kiểu sharding này chỉ nên sử dụng cho loại dữ liệu key-value trong đó loại dữ liệu phải giống nhau (không quá khác biệt).

Dynamic sharding

Trong kiểu sharding này, cần có một locator service chạy riêng biệt giúp xác định việc lưu trữ dữ liệu ở đâu. Để đọc và ghi dữ liệu, client cần kết nối và truy vấn vô locator service trước tiên. Locator sẽ thực hiện việc điều phối các hoạt động lưu trữ dữ liệu trong cluster một cách linh động. HDFS, Apache HBase, MôngDB đều sử dụng kiểu sharding này.

---
Vitess là công cụ nguồn mở giúp việc mở rộng Mysql theo chiều ngang (horizontal scaling or sharding) được thực hiện dễ dàng, đây là một trong những core infrastructure của Youtube

Vitess: https://github.com/vitessio/vitess
Sharding thực hiện ở instagram: https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

Friday, 4 October 2019

Học Data Structures & Algorithms phỏng vấn xin việc

Hầu như các công ty công nghệ lớn làm sản phẩm khi tuyển nhân viên họ đều muốn tìm các ứng viên có kiến thức tốt về cấu trúc dữ liệu và thuật toán. Với những người mất gốc và tưởng lầm thời gian học đại học là để chơi game, tán gái như tôi thì việc tự học cấu trúc dữ liệu và thuật toán là một việc không dễ dàng.

Một trong những khoá tôi cảm thấy học dễ vô nhất về cấu trúc dữ liệu và thuật toán là khoá học Intro to Data Structures and Algorithms trên Udacity, ngoài việc cấu trúc khoá học được thiết kế chi tiết dễ theo dõi không yêu cầu các kiến thức chuyên sâu khác để theo được hết khoá học, còn có lẽ là do cô giảng viên xinh đẹp tóc vàng Brynn



Ngoài việc học được các kiến thức cơ bản nhất về cấu trúc dữ liệu và thuật toán, khoá học này còn giúp bạn một số kỹ năng để đi phỏng vấn ở các công ty công nghệ lớn như Google, Facebook ... nghe thế này cũng đáng để học rồi đấy.

Cấu trúc chính của khoá học sẽ nói về các hiệu quả của các chương trình và các đo hiệu quả các chương trình đó bằng Big O(). Tiếp sẽ giới thiệu về các cấu trúc dữ liệu, cách triển khai các cấu trúc này trong python như list, maps, trees, graphs ... các thuật toán chính trong searching và sorting như binary search, bubble sort, merge sort, quick sort ...

Phần cuối của khoá sẽ có một vài cách để trả lời các câu hỏi phỏng vấn về cấu trúc dữ liệu và thuật toán, có phần giả lập đi kèm xem rất giống thật.

  1. Introduction and Efficiency
  2. List-Based Collections
  3. Searching and Sorting
  4. Maps and Hashing
  5. Trees
  6. Graphs
  7. Case Studies in Algorithms
  8. Technical Interview Tip
Một điều hấp dẫn khác là  khoá học này miễn phí trên Udacity, bạn nào muốn tự mình khám phá thì nhào vô link ở đây để học ngay thôi, bạn nào muốn tìm bạn để trao đổi thảo luận về nội dung khoá học thì để lại còm men ở dưới bài này nhé.


Sunday, 25 November 2018

Làm thế nào chạy nhiều ứng dụng trên kubernetes


Introduction

Một trong các vấn đề khi chạy sản phẩm trên internet public phục vụ số lượng người dùng lớn mà chúng ta thường gặp phải là khả năng mở rộng (Scalability) của hệ thống. Khi số lượng người dùng tăng lên với số lượng lớn, một hệ thống muốn đáp ứng được thì cần phải có tính mở rộng, tăng lượng tài nguyên để đảm bảo khả năng đáp ứng số lượng truy cập của người dùng tăng.




Kubernetes (thường gọi tắt là k8s) đang trở nên thông dụng với việc số lượng các công ty (cả enterprises lẫn startups) sử dụng k8s đang tăng lên nhanh chóng. K8s được ưa chuộng không chỉ bởi số star trên github của project đang là 42,941 với 1860 contributors (thời điểm viết bài), mà còn do các tính năng vượt trội mà nó mang lại trong việc thực hiện deployment, maintenance, và scaling các ứng dụng chạy trên đó.

Tìm hiểu thêm về Kubernetes trên Github

Trong bài viết này tôi sẽ chia sẻ về cách chúng tôi dùng Kubernetes, cụ thể là GKE (Google Kubernetes Engine), để chạy sản phẩm của dự án và Gitlab CI để hỗ trợ thực hiện tích hợn liên tục CI (Continuous Integration) giúp tăng tốc độ quá trình phát triển sản phẩm.

Tech Stack

Một trong các ưu điểm của k8s, phù hợp để chạy các ứng dụng microservice, trong đó mỗi service có thể được phát triển dùng các ngôn ngữ, công nghệ khác nhau và được đóng gói vào trong các docker image riêng biệt. Dưới đây là một số công nghệ và framework mà chúng tôi sử dụng trong dự án.

  • nodejs – phát triển frontend
  • vuejs – phát triển cms client
  • akka-http – phát triển backend (rest api)
  • docker – đóng gói ứng dụng
  • kubernetes – chạy, quản lý, điều phối docker container
  • google kubernetes engine (gke) – chạy kubernetes cluster
  • google cloud sql – chạy mysql database
  • gitlab ci – lưu trữ source code và thực hiện tích hợp liên tục


Dockerize Application

Đầu tiên chúng tôi cần viết các Dockerfile cho từng service frontend/cms/backend, Dockerfile là nơi viết các hướng dẫn, câu lệnh để build các docker images.

Dockerfile cho frontend, thực hiện cài đặt thư viện phụ thuộc, build nodejs app, sau đó copy kết quả vào image. Mở port 3000 cho kết nối từ bên ngoài, chạy lệnh npm start khi bật container.

Tương tự cho các service cms và backend, chúng tôi cũng cần viết Dockerfile để đóng gói source code của ứng dụng vào trong docker image. Phần backend chúng tôi dùng sbt plugin là sbt-native-package để build docker image.

Kubernetes

Sau khi application đã được đóng gói vào trong các docker images bằng Dockerfile, bước tiếp theo cần tìm cách để chạy các containers từ các images này một cách hiệu quả? Đây là thời điểm k8s trở nên hữu ích với các tính năng scale không giới hạn của mình (thực ra giới hạn hiện tại của k8s thời điểm viết bài này là 5000 nodes, 100 pods trên một node, tổng số pods là 150000, tổng số containers là 300000).

Để chạy một ứng dụng trên k8s, chúng tôi viết các manifest file cho ứng dụng đó. Đây là các file (ở định dạng YAML) đặc tả chứa những thông tin liên quan tới việc chạy container trên k8s chẳng hạn như : tên image, container port, biến môi trường, đánh label … Trong k8s manifest file sẽ cần có 2 thành phần chính là DeploymentService.

  • Deployment : sẽ đảm bảo các containers chạy đúng về số lượng, cấu hình với cài đặt như trong manifest file
  • Service : giống như một endpoint được exposed để cho phép truy cập từ bên ngoài

Dưới đây là k8s manifest file cho frontend service : frontend.yaml

Để áp dụng các manifest file này lên k8s cluster, chúng tôi dùng kubectl (kubernetes client). Đây là một ứng dụng dòng lệnh giúp tương tác với k8s cluster. Trước khi dùng kubectl chúng tôi cần thực hiện việc cấu hình xác thực để kubectl làm việc với k8s cluster. Lệnh phía dưới sẽ đọc nội dung của file frontend.yaml, gọi vào API của k8s cluster để thực hiện lệnh theo yêu cầu.

kubectl create -f frontend.yaml


Một cách khác chuyên nghiệp hơn (maybe ;)) là viết manifest này thành một helm chart để deploy lên cluster, nếu các bạn muốn có thể tìm hiểu thêm về helm ở đây

Ngoài Deployment và Service, còn có các thành phần khác mà chúng tôi cần phải cài đặt để giúp hoàn thiện việc triển khai app chạy trên k8s.

  • ingress : quản lý, điều khiển các request vào các service phía trong k8s, chúng tôi chọn nginx-ingress được cộng đồng hỗ trợ tốt với nhiều tính năng, dễ dàng cài đặt và sử dụng cho những người đã có kinh nghiệm với nginx.
  • service account : giúp phân quyền truy cập thao tác vào k8s cluster
  • configmap, secret : lưu trữ các cấu hình, tham số
  • persistent volume : dùng cho các dữ liệu cần lưu trữ lâu dài


Google Kubernetes Engine

Để triển khai và chạy k8s cluster, chúng tôi cân nhắc các lựa chọn :

  • Amazon Cloud AWS thì có thể dùng EKS (service cung cấp bởi AWS) hoặc sử dụng Kops xây dựng bởi cộng đồng
  • Microsoft Cloud Azure có AKS
  • Google Cloud GCP có GKE

Sau khi cân nhắc về khía cạnh maturity (mức độ ổn định của một sản phẩm), tính đơn giản dễ sử dụng chúng tôi đã quyết định lựa chọn GKE, một điểm cộng cho GKE là các maintainer chính của Kubernetes open source cũng là những người xây dựng nên GKE

Trên GKE chúng tôi tạo 2 Kubernetes cluster :

  • development cluster sử dụng cho môi trường test/staging
  • production cluster sử dụng cho môi trường live/production


Gitlab CI

Cuối cùng chúng tôi dùng Gitlab CI để tự động hoá các bước test, build, package và deploy. Việc thực hiện CI trên Gitlab được thiết lập qua .gitlab-ci.yml file. Các bước trong .gitlab-ci.yml :

  • test : chạy unit test code
  • build : chạy các job build
  • package : đóng gói docker image và đẩy lên image registry (gitlab có tích hợp sẵn)
  • deploy : chạy deploy lên k8s clusterfile .gitlab-ci.yml của frontend mô tả các jobs (test, build, package, deploy) sẽ tự động chạy khi có code được merge vào nhánh develop trên Gitlab.
Tạo .gitlab-ci.yml file của frontend mô tả các jobs (test, build, package, deploy) sẽ tự động chạy khi có code được merge vào nhánh develop trên Gitlab :

Conclusion

Đến đây chúng tôi đã xây dựng cơ bản một ứng dụng có thể chạy trên k8s cluster. Trong thời gian tiếp theo, chúng tôi sẽ tập trung vào các best practice để áp dụng vào hệ thống, giúp cải thiện hiệu năng, tiết kiệm tài nguyên và tăng tính bảo mật của hệ thống.

Cám ơn bạn đã đọc bài, welcome các ý kiến đóng góp của các bạn. Hãy để lại comments ở dưới bài viết.

Thursday, 7 July 2016

Terraform, một công cụ để làm Infrastructure as Code


Bạn đã nghe về "Infrastructure as Code" chưa ? Bạn có biết Terraform không? Có thể có ,có thể không nhưng dù sao hãy đọc bài viết này. Tôi sẽ viết về chúng trong sự hiểu biết của mình, và nếu bạn thấy thú vị chúng ta có thể thảo luận cùng nhau.

Infrastructure as Code là một phương pháp trong đó bạn sẽ viết các đoạn mã để xây dựng hạ tầng cho sản phẩm của mình. Hạ tầng cho sản phẩm bao gồm các thành phần chính :


  •  hệ thống mạng           :  đảm bảo việc truy cập vào ra thông suốt và an toàn
  •  hệ thống tính toán     :  cung cấp tài nguyên tính toán cho các ứng dụng, tiến trình xử lý
  •  hệ thống lưu trữ         :  cung cấp tài nguyên, giải pháp lưu trữ dữ liệu và thông tin
  •  hệ thống email, DNS  : cung cấp dịch vụ liên quan tới email, DNS
  •  hệ thống giám sát      :  theo dõi và cảnh báo hoạt động của hệ thống


Có nhiều cách để xây dựng cơ sở hạ tầng cho sản phẩm như : mua Server đặt ở các trung tâm dữ liệu, thuê mua VPS VMs, tự xây dựng trung tâm dữ liệu của mình, sử dụng dịch vụ cloud computing của Google (GCP), của Amazon (AWS), của Microsoft (Azure) ...


Vậy Terraform thì có liên quan gì đến mấy thứ ở trên? Terraform là một công cụ nguồn mở giúp thực hiện "Infrastructure as Code" thuận tiện và dễ dàng hơn, viết bằng ngôn ngữ Go khởi xướng bởi Hashicorp. Terraform GitHub Repository

Với tính năng linh hoạt Terraform có thể làm việc với nhiều hãng và nền tảng cung cấp dịch vụ hạ tầng khác nhau như : Atlas, Heroku, AWS, GCP, OpenStack, DigitalOcean, ... tham khảo thêm tại đây.

Terraform so sánh với một số công cụ khác :

* Chef, Puppet, Ansible : các công cụ này có chức năng provision cho các máy đã tồn tại, nhiệm vụ chính của Terraform là provision các máy và cách chúng được sắp đặt và liên kết với nhau.
* CloudFormation : chức năng tương tự nhưng chỉ dùng cho AWS, Terraform có thể làm việc với nhiều hãng và nền tảng khác nhau như đã nói ở phía trên.
* Boto, fog : đây là các thư viện ở mức thấp giúp người dùng tương tác với APIs của các Providers, Terraform cung cấp cho người dùng các syntax ở mức cao, dễ sử dụng hơn.
Bạn có thể xem thêm chi tiết ở đây.

Chúng ta hãy tìm hiểu chi tiết bằng một ví dụ đơn giản, xây dựng hạ tầng cho một sản phẩm trên nền tảng AWS gồm có 1 EC2 instance đặt ở Public subnet, 1 RDS instance đặt ở Private subnet.



Các bước cơ bản cần thực hiện :

B1: Cài đặt TerraformAWS credential cho phép xác thực khi tương tác với các API của AWS để thực hiện các yêu cầu

B2 :Clone từ ví dụ từ github (hoặc bạn có thể tự viết sau khi đã thành thạo) về một thư mục trên máy chẳng hạn như terraform-example. Terraform sử dụng các Terraform configurations files với đuôi .tf để người dùng thiết lập các mô tả cho hạ tầng của mình,  trong ví dụ này sẽ gồm có :

* main.tf : file này chứa các đoạn mã để tạo tài nguyên theo mong muốn. Ví dụ đoạn mã dưới đây của terraform sẽ tạo một EC2 instance với loại instance là m1.small, sau đó cài đặt và bật nginx trên instance đó.

resource "aws_instance" "web" { 
# The connection block tells our provisioner how to
# communicate with the resource (instance)
connection {
# The default username for our AMI
user = "ubuntu"
# The connection will use the local SSH agent for authentication.
instance_type = "m1.small" 
# Lookup the correct AMI based on the region
# we specified 
ami = "${lookup(var.aws_amis, var.aws_region)}" 
# The name of our SSH keypair we created above. 
key_name = "${aws_key_pair.auth.id}"
# Our Security group to allow HTTP and SSH access 
vpc_security_group_ids = ["${aws_security_group.default.id}"] 
# We're going to launch into the same subnet as our ELB. In a production
# environment it's more common to have a separate private subnet for
# backend instances.
subnet_id = "${aws_subnet.default.id}" 
# We run a remote provisioner on the instance after creating it.
# In this case, we just install nginx and start it. By default,
# this should be on port 80
provisioner "remote-exec" {
inline = [
"sudo apt-get -y update",
"sudo apt-get -y install nginx",
"sudo service nginx start"
]
}
}

* variables.tf : file này chứa các biến được sử dụng trong file main.tf ở phía trên, bạn có thể truyền giá trị cho các biến này cũng như thiết lập giá trị mặc định. Đoạn mã dưới định nghĩa một biến là aws_region với giá trị mặc định là "us-west-2".

variable "aws_region" {
description = "AWS region to launch servers."
default = "us-west-2"
}

* outputs.tf : file này chứa các giá trị sẽ được truyền ra ngoài giúp cho các modules khác có thể sử dụng giá trị này truyền cho biến của mình. Đoạn mã dưới sẽ đưa ra địa chỉ public dns của instance vừa tạo ở trên.

output "address" {
value = "${aws_instance.web.public_dns}"
}

* Trong quá sử dụng terraform, sẽ có thêm 2 files được sinh ra để lưu trạng thái hiện tại của các tài nguyên đã được tạo :

terraform.tfstate
terraform.tfstate.backup

Source code cho ví dụ này bạn có thể tìm thấy ở đây.

B3 : Chạy lệnh $ terraform plan để kiểm tra và hiển thị trước những tài nguyên sẽ được tạo.
B4 : Chạy lệnh $ terraform apply để bắt đầu tạo tài nguyên từ các file .tf mô tả ở trên.

Cuối cùng, nếu muốn xoá toàn bộ tài nguyên vừa được tạo ở trên chúng ta có thể dùng lệnh $terraform destroy, hãy cẩn thận với môi trường thật khi thực hiện lệnh này ;)

Bài viết giới thiệu tổng quát về khái niệm Infrastructure as Code và một công cụ để thực hiện nó, Terraform. Từ đó bạn có thể tìm hiểu sâu hơn về chúng để có thể áp dụng vào việc giải quyết các vấn đề về hạ tầng một cách linh hoạt và hiệu quả.

Cám ơn bạn đã đọc bài viết.

Monday, 11 April 2016

Continuous Integration with CloudFormation, Ansible, Jenkins, Docker, ECS

Có bao giờ bạn muốn code của mình sau khi viết xong được kiểm tra ngay tức thời với hệ thống đang chạy trên các môi trường test, stagging, thậm chí là trên production ? Làm thế nào để tăng tốc quá trình phát triển ứng dụng thông qua việc phát hiện lỗi càng sớm càng tốt ? Nếu câu trả lời là có, xin mời bạn tiếp tục theo dõi bài viết.

Bài viết sẽ đưa ra một ví dụ tổng quát về việc sử dụng các công cụ, dịch vụ phối hợp với nhau để thực hiện Continous Integration (CI) trong quá trình phát triển phần mềm.

Mô hình tổng quan gồm có những gì ?

CloudFormation : một dịch vụ của AWS hỗ trợ việc quản lý, xây dựng các tài nguyên trên Amazon Web Service (AWS) một các tự động thông qua các APIs và Json templates. Tham khảo thêm ở đây.

Chức năng : cung cấp các tài nguyên cần thiết trên AWS cho dự án, trong ví dụ này chúng ta sẽ cần :

  • 01 EC2 instance để cài đặt Jenkins (CI server)
  • 01 ELB xử lý việc cân bằng tải
  • 01 RDS instance cho lưu trữ dữ liệu
  • 01 ECS cluster để chạy, điều phối các docker containers
  • 01 ECR registry để lưu trữ các docker images




Ansible : một công cụ, ngôi sao đang lên, trong việc quản lý cấu hình tự động cho các machines. Tham khảo thêm tại đây.

Chức năng : cung cấp việc cài đặt và thiết lập môi trường cũng như các packages cần thiết cho CI server :
  • Nginx với chức năng reverse proxy cho jenkins
  • Jenkins với chức năng CI server
  • Docker với chức năng build docker image
  • Aws CLI tương tác với ECS, ECR qua dòng lệnh

Jenkins : CI server, một sản phẩm mã nguồn mở giúp tự động hóa các công việc building, deploying các phần mềm, dự án. Tham khảo thêm tại đây.

Chức năng : cung cấp hõ trợ cấu hình chạy unit test, build, deploy cho dự án.

Docker : một công cụ giúp đóng gói và phân phối ứng dụng dễ dàng, đa nền tảng. Tham khảo thêm tại đây.

Chức năng : đóng gói và phân phối các ứng dụng thông qua các docker images.

ECS : EC2 Container Service. Một dịch vụ của AWS thực hiện việc điều phối, quản lý, liên kết các docker container để làm việc hiệu quả. Tham khảo thêm tại đây.

Chức năng : cung cấp việc vận hành và điều phối các docker containers.

ECR : EC2 Container Registry. Một dịch vụ của AWS để lưu trữ các docker images, chức năng tương tự như DockerHub. Từ đấy các hệ thống có thể lấy docker image theo yêu cầu.

Vậy các bộ phận trên phối hợp với nhau như thế nào ?


  1. Engineer push code tới git repository
  2. Jenkins định kỳ kiểm tra và pull code mới về
  3. Jenkins chạy Unit test
  4. Jenkins chạy docker build để đóng gói ứng dụng vào docker image
  5. Jenkins pushs docker image tới ECR
  6. Jenkins trigger deploy tới ECS để lấy docker image mới từ ECR


Các bước trên được thực hiện tuần tự cho tới khi tất cả các bước được hoàn thành tạo nên một chu trình khép kín CI.

Như vậy chúng ta đã có một mô hình tổng quát về CI tích hợp các công cụ có sẵn AWS, Docker, Jenkins, Ansible. Việc tích hợp CI sẽ đẩy nhanh quá trình phát hiện lỗi thông qua việc tự động hóa. Giúp cho người viết mã có thể sớm sửa lỗi, góp phần tăng tốc quá trình đưa những cập nhật mới của ứng dụng tới người dùng.

Chi tiết từng bước sẽ được tác giả tiếp tục cập nhật ở các bài viết tiếp theo. Rất mong nhận được ý kiến của bạn đọc

Sunday, 27 December 2015

Làm việc với người Nhật


Từ trước tới giờ tôi vẫn hay nghe nói nhiều về sự phát triển thần kỳ của đất nước Nhật Bản. Người ta nói nhiều về sự thành công của đất nước này, sự thành công đó tất nhiên là đến từ con người Nhật Bản, bởi vì đất nước của họ thiên nhiên không phải mưa thuận gió hòa như đất nước nào đó ở vùng Đông Nam Á vẫn thường tự hào :)



Cũng chỉ nghe nói về đất nước và con người Nhật Bản như vậy nhưng tôi đã không hiểu được nhiều ở thời điểm đó. Sau một thời gian làm việc cho các công ty Nhật, hơn 5 năm 6 tháng 7 ngày, tôi có thể một phần nào hiểu được tại sao nước Nhật lại có thể đạt được nhiều thành tựu trong thời gian ngắn tới như vậy.

Bài viết này ghi lại một số kinh nghiệm, có cả những cảm nhận, về tính cách (chủ yếu là thái độ trong công việc) của những người Nhật mà tôi có dịp làm việc chung.

. Tính trung thực
   Không nói dối, luôn báo cáo tình trạng dù có tồi tệ thế nào. Bởi vì che giấu vấn đề chỉ giải quyết được vấn đề trốn tránh trách nhiệm tại thời điểm đó, tệ hại hơn nữa là làm cho người khác hiểu biết lệch lạc về vấn đề, dẫn tới không kiểm soát được hậu quả.
 
. Trách nhiệm cao, chăm chỉ
   Khi đã nhận làm một việc gì đó, người Nhật luôn làm với một tinh thần cực cao. Như thể nếu việc này mà không hoàn thành thì họ muối mặt lắm, bị đau khổ lắm, dằn vặt lắm. Do đó họ làm việc rất chăm chỉ, công việc hôm nào chưa xong thì ngồi lại tới 9, 10 giờ khuya để làm.

. Tính khiêm tốn
    Luôn tỏ thái độ khiêm tốn với người khác, cúi chào nhau khi gặp mặt. Đồng thời cũng luôn thể hiện một đầu óc luôn học hỏi, cập nhật tri thức mới.

. Sự giúp đỡ
    Sắn sàng giúp đỡ người khác nếu mình có thể giúp được một cách nhiệt tình, không tính toán so đo.

. Làm việc nhóm, trao đổi
      Kỹ năng trao đổi thông tin trong nhóm rất tốt, mọi thông tin được truyền tải qua lại giữa tất cả thành viên trong nhóm dù là việc nhỏ nhất. Ngoài ra, mỗi thành viên sẽ cố gắng làm một việc trọn vẹn và chi tiết, sau đó chia sẻ với người khác. Như vậy một người làm giỏi một việc, giúp đỡ người khác và công việc sẽ hoàn thành tốt hơn.

.Tinh thần cải tiến
    Khi gặp vấn đề, lỗi. Tập trung vào việc khắc phục sự cố trước. Sau đó tìm hiểu tại sao lại xảy ra lỗi đó, làm thế nào để lần sau không xảy ra. Tất nhiên người gây ra lỗi cũng cần có trách nhiệm báo cáo vấn đề, nhưng không phải để trách móc, chế giễu mà để lần sau không xảy ra tình trạng này.

Đó là những gì tôi thấy và học hỏi trong thời gian làm việc cùng với một số đồng nghiệp người Nhật. Viết ra những đức tính tốt của họ không phải để tự ti, thấy mình thấp kém. Mà để học hỏi, học tập. Cải thiện bản thân ngoài kiến thức chuyên môn cần có tác phong làm việc chuyên nghiệp, tính cộng đồng để hội nhập thế giới.

Bucket list của tôi

Trong tiếng anh có một thuật ngữ "bucket list", được định nghĩa như này: -  a number of experiences or achievements that a person ...