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.

Monday, 2 November 2015

Xây dựng môi trường phát triển với Docker compose



Docker-composer-emotion



Tiếp nối bài viết trước Giới thiệu về Docker, bài viết này sẽ giới thiệu một công cụ để quản lý và chạy nhiều docker containers liên kết với nhau để xây dựng một môi trường phát triển ở local cho các developers, đó là công cụ docker compose.

1. Docker compose là gì

  . Định nghĩa

 "Compose is a tool for defining and running multi-container applications with Docker. With Compose, you define a multi-container application in a single file, then spin your application up in a single command which does everything that needs to be done to get it running."

 Bạn có thể tham khảo thêm thông tin chi tiết về docker compose ở đây

2. Xây dựng môi trường phát triển với docker compose

  2.1 Mục tiêu : xây dựng một môi trường phát triển local gồm các thành phần ở dưới -Reverse proxy : nginx -Framework : play-framework/scala -Database : Mysql 5.6

  2.2 Phân tích : sử dụng docker compose để quản lý và liên kết 3 containers, mỗi container chạy 1 service như ở trên gồm có nginx, play-framework/scala và mysql server
docker-composer-containers
2.3 Cài đặt docker compose : tham khảo ở đây

2.4 Thiết lập cấu hình và chạy docker compose cho project

 Tạo một folder có cấu trúc như hình bên dưới, bạn có thể đặt tên theo project hoặc tùy ý, ở đây tạm đặt là docker-compose

docker-compose-folders

Trong đó :
  • docker-compose/ : thư mục gốc lưu trữ
  • docker-compose/app_web : thư mục lưu trữ mã nguồn của ứng dụng play-framework/scala
  • docker-compose/mysql : thư mục lưu trữ Dockerfile dùng để xây dựng và chạy mysql-server container
    • Dockerfile (mysql container)
      FROM mysql/mysql-server:5.6
      ENV MYSQL_DATABASE=app_dev
      ENV MYSQL_USER=app_web
      ENV MYSQL_PASSWORD=pleasechangeme
      ENV MYSQL_ROOT_PASSWORD=pleasechangemetoo
  • docker-compose/nginx : thư mục lưu trữ Dockerfile, file cấu hình nginx dùng để xây dựng và chạy nginx container
    • Dockerfile (nginx container)
      FROM centos:centos6
      MAINTAINER longlx (long_lx@septeni-technology.jp)
      # Install epel repository
      RUN yum install -y http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm && yum update -y && yum clean all -y
      # Install nginx
      RUN yum install -y nginx
      # Remove the default nginx configuration file
      RUN rm -v /etc/nginx/nginx.conf
      # Copy a configuration file from the current directory
      ADD nginx.conf /etc/nginx/
      ADD app.local.conf /etc/nginx/conf.d/
      # Append "daemon off;" to the beginning of the configuration
      RUN echo "daemon off;" >> /etc/nginx/nginx.conf
      CMD service nginx start
  • docker-compose/Dockerfile : Dockerfile dùng để xây dựng và chạy play-framework/scala container
    • Dockerfile (play-framework/scala container)
      FROM centos:centos6
      MAINTAINER longlx (long_lx@septeni-technology.jp)
      # install java 8
      RUN yum install -y java-1.8.0-openjdk java-1.8.0-openjdk-devel && \
      yum clean all
      # install activator
      RUN yum update -y && yum install -y unzip
      RUN curl -O http://downloads.typesafe.com/typesafe-activator/1.3.6/typesafe-activator-1.3.6.zip
      RUN unzip typesafe-activator-1.3.6.zip -d /opt && mv /opt/activator-* /opt/activator-1.3.6/ && \
      rm typesafe-activator-1.3.6.zip && chmod a+x /opt/activator-1.3.6/activator
      ENV PATH $PATH:/opt/activator-1.3.6
      RUN mkdir /app_web
      WORKDIR /app_web
      # copy source code to container's volume
      COPY app_web /app_web
      CMD ["activator", "run"]
  • docker-compose/docker-compose.yml : file cấu hình mà docker compose sẽ sử dùng để đọc thông tin cấu hình khi chạy lệnh "docker-compose up"
    • docker-compose.yml
      nginx:
        build: ./nginx
        ports:
          - "8080:80"
        volumes_from:
          - web
        links:
          - web 
      web:
        build: .
        ports:
          - "9000:9000"
        volumes:
          - /root
        links:
          - mysql
        tty: true 
      mysql:
        build: ./mysql
        ports:
          - "3006:3006"
Đến đây việc chuẩn bị cấu hình cho docker compose đã hoàn tất. Tiếp theo chúng ta sẽ build các images từ Dockerfile và run các containers từ các images đó :
lx:~$cd docker-compose
# build images
lx:~/docker-compose$ docker-compose build
# run and link containers
lx:~/docker-compose$ docker-compose up

Hiển thị các containers đang chạy bằng lệnh :
lx:~/docker-compose$ docker-compose ps
Name Command State Ports
-------------------------------------------------------------------------------------------------
dockercompose_mysql_1 /entrypoint.sh mysqld Up 0.0.0.0:3006->3006/tcp, 3306/tcp
dockercompose_nginx_1 /bin/sh -c service nginx start Up 0.0.0.0:8080->80/tcp
dockercompose_web_1 activator run

Hiển thị logs của web containter bằng lệnh :
lx:~/docker-compose$ docker logs -f dockercompose_web_1
--- (Running the application, auto-reloading is enabled) ---
[info] p.a.l.c.ActorSystemProvider - Starting application default Akka system: application
[info] p.c.s.NettyServer - Listening for HTTP on /0:0:0:0:0:0:0:0:9000
(Server started, use Ctrl+D to stop and go back to the console...)
[info] Compiling 130 Scala sources and 2 Java sources to /app_web/target/scala-2.11/classes...
[info] 'compiler-interface' not yet compiled for Scala 2.11.6. Compiling...
[info] Compilation completed in 9.253 s

Bây giờ bạn có thể truy cập từ trình duyệt http://app.local:8080/ để kiểm tra kết quả.


2.5 Tổng kết : như vậy bạn đã có một môi trường phát triển hoàn chỉnh gồm các stacks : nginx/play-framework/mysql trên máy của mình chỉ với một vài thao tác sử dụng docker, docker compose. Việc chia sẻ với các developers khác cũng trở nên dễ dàng hơn, bạn chỉ cần đưa lên một source repository hoặc đẩy các images lên Docker Hub và các thành viên khác có thể sử dụng và đóng góp. Hiện tại trong tài liệu chính thức của docker compose không khuyến nghị sử dụng cho production, chỉ nên sử dụng ở môi trường development, staging, continous integration. Hy vọng trong tương lai gần chúng ta có thể sử dụng docker compose cho tất cả các môi trường giúp cho việc phát triển và phân phối các ứng dụng trở nên dễ dàng và trơn tru hơn. Một vấn đề nữa là khi mount một thư mục trên máy linux đã được mã hóa ổ đĩa, với một thư mục trên play-framework/scala container thì lúc biên dịch sbt sẽ báo lỗi :
"play.sbt.PlayExceptions$CompilationException: Compilation error[File name too long]"
Nguyên nhân có thể do giới hạn class file name của sbt và giới hạn của bản thân docker container. Khi có giải pháp cho vấn đề này người viết bài sẽ cập nhật.

 Thank you for reading, all comments are welcome !

Monday, 28 September 2015

AWS CloudFormation là gì?



Nếu đã từng làm việc trên AWS (Amazon Web Service) - môi trường cloud computing của Amazon - có thể bạn sẽ cần nhiều tới sự trợ giúp của CloudFormation - một công cụ để "tài liệu hóa" nguồn tài nguyên ( EC2 instances, RDS database , VPC ...) trên AWS.
Việc sử dụng CloudFormation giúp tái sử dụng các tài nguyên trên AWS dễ dàng và tự động. Giúp tiến gần tới khái niệm "Infrastructure as Code", một thuật ngữ mới trong nghành phát triển các sản phẩm phần mềm hiện đại.
Mục tiêu của bài viết này chia sẻ kiến thức cơ bản về CloudFormation, cách sử dụng nó qua một số ví dụ.

I. Một số khái niệm

1. Templates

Thành phần cốt lõi để CloudFormation làm việc là các templates. Nếu bạn là người thích liên tưởng, thì các templates giống như các bản thiết kế, phác thảo trong ngành xây dựng vậy. Nếu không thì đây là các tài liệu ở định dạng JSON, định nghĩa danh sách các tài nguyên, cấu hình của chúng mà bạn muốn sử dụng để xây dựng môi trường cho sản phẩm của mình trên AWS. Bạn sẽ định nghĩa trước các thành phần, bộ phận mà bạn muốn có ở đây. Sau đó Cloudformation sẽ đọc và thực thi theo yêu cầu của nội dung chứa trong các templates này.
Một template có cấu trúc như ở bên dưới :

{"AWSTemplateFormatVersion" : "version date","Description" : "JSON string",
"Metadata" : {
template metadata
},
"Parameters" : {
set of parameters
},
"Mappings" : {
set of mappings
},
"Conditions" : {
set of conditions
},
"Resources" : {
set of resources
},
"Outputs" : {
set of outputs
}
}

2. Stack

Stack là một thực thể của template, nó là một ngăn xếp giúp quản lý tập hợp các tài nguyên AWS đang được sử dụng trong cùng một nhóm. Bạn có thể hình dung như stack là một ngôi nhà cụ thể được xây dựng từ bản thiết kế ( các templates ). Nó là các tài nguyên đang được sử dụng thực, không còn là khái niệm trên các templates nữa.


II. Một số ví dụ


Công ty vừa phát triển một sản phẩm mới trên LAMP, bạn được yêu cầu chuẩn bị cơ sở hạ tầng và môi trường để sản phẩm chạy được trên AWS.

Đầu tiên phân tích các thành phần, stacks trên AWS sẽ gồm có :
- VPC : một data center ảo bao gồm subnets, routing tables, internetgateway
- EC2 : server ảo chạy Amazon linux, Public IP address
- RDS : database ảo chạy Mysql

Bây giờ bạn sẽ cần phải chuẩn bị các templates cho mỗi stack ở trên. Trong các templates này, bạn sẽ định nghĩa những thành phần cần thiết ở đây theo định dạng JSON. Ví dụ một đoạn JSON như dưới :
"Resources" : {"EC2Instance" : {"Type" : "AWS::EC2::Instance","Properties" : {"InstanceType" : { "Ref" : "InstanceType" },"SecurityGroupIds" : [ { "Ref" : "DevBaseWebVPCSecurityGroupID" }, { "Ref" :       "DevProductVPCSecurityGroupID" } ],"KeyName" : { "Ref" : "KeyName" },"SubnetId": { "Ref" : "DevPublicSubnet1AID" },"PrivateIpAddress" : { "Ref": "PrivateIPAddress" },"BlockDeviceMappings" : [ {"DeviceName" : "/dev/xvda", "Ebs" : { "VolumeSize" : "30" }} ],"ImageId" : { "Fn::FindInMap" : [ "AWSRegionArch2AMI", { "Ref" : "AWS::Region" },{ "Fn::FindInMap" : [ "AWSInstanceType2Arch", { "Ref" : "InstanceType" }, "Arch" ] } ] },"Tags": [{"Key": "Name","Value": { "Ref" : "InstanceName" }}} } }
Trong ví dụ trên bạn sẽ tạo một EC2 instance với các đặc điểm được định nghĩa trước, bạn có thể điền giá trị trực tiếp trong template hoặc truyền vào giống tham số sau như ở phía dưới:
  • InstanceType
  • SecurityGroupIds
  • KeyName
  • SubnetId
  • PrivateIpAddress
  • BlockDeviceMappings
  • ImageId
  • Tags
Chuẩn bị Cloudformation template cho stack VPC, một ví dụ mẫu của VPC template bạn có thể xem ở đây.

Sau khi chuẩn bị xong vpc template, giả sử bạn lưu ở thư mục cloudformation/vpc_template.json. Có nhiều cách sử dụng template này, qua web console, aws command line, api. Ở đây bạn sẽ dùng aws command line, chạy lệnh dưới để tạo stack sử dụng vpc template bạn vừa tạo ở trên :
aws cloudformation create-stack --stack-name vpc-base-network --template-body file:///cloudformation/vpc_template.json

Tương tự cho các stacks EC2, RDS còn lại.

Chuẩn bị Cloudformation template cho stack EC2, một ví dụ mẫu của EC2 template bạn có thể xem ở đây.
Sau khi chuẩn bị xong ec2 template, giả sử bạn lưu ở thư mục cloudformation/ec2_template.json. Chạy lệnh dưới để tạo stack sử dụng ec2 template bạn vừa tạo ở trên, bạn có thể truyền tham số vào template :
aws cloudformation create-stack --stack-name dev-ec2-web --template-body file:///cloudformation/ec2_template.json --parameters ParameterKey=KeyName,ParameterValue=keys.dev ParameterKey=SubnetID,ParameterValue=subnet-a1b2c3d4

Chuẩn bị Cloudformation template cho stack RDS, một ví dụ mẫu của RDS template bạn có thể xem ở đây.
Sau khi chuẩn bị xong rds template, giả sử bạn lưu ở thư mục cloudformation/rds_template.json. Chạy lệnh dưới để tạo stack sử dụng rds template bạn vừa tạo ở trên, bạn có thể truyền tham số vào template :
aws cloudformation create-stack --stack-name dev-rds --template-body file:///cloudformation/dev/rds.json --parameters ParameterKey=DBSecurityGroup,ParameterValue=sg-f677e293 ParameterKey=DBSubnetGroup,ParameterValue=vpc-network-devdbsubnetgroup-19mk1hlxxx



Như vậy là bạn đã xây dựng xong cho mình một môi trường hoàn chỉnh trên AWS bao gồm ba stacks chính là VPC, EC2, RDS sẵn sàng cho việc deploy các sản phẩm tuyệt vời lên đó rồi. Các developers khó tính chắc chắn cũng khó để không hài lòng.

Thursday, 13 August 2015

Divide and conquer - khái niệm "vạn năng"

Tôi thấy bài viết này hay hữu ích, dịch lại để nhớ phòng khi cần áp dụng :)) 

Ý tưởng chính là mọi vấn đề dù phức tạp đến đâu đều có thể giải quyết bằng phương pháp chia để trị, vấn đề phức tạp sẽ được chia thành càng vấn đề càng nhỏ càng tốt. Nhỏ tới mức đơn giản để giải quyết. Một ví dụ tôi có thể nghĩ ra là chiếc máy tính của bạn làm được rất nhiều việc phức tạp như lướt web coi phim, làm văn bản, nhận diện giọng nói mặt người ... nhưng các việc máy tính làm ở phía dưới chỉ là các phép toán cộng, trừ, lấy dư ... của CPU với các bit 0,1 mà thôi



----

Divide and conquer (chia để trị) là tên của một nhóm các thuật toán giải quyết các vấn đề bằng cách đệ quy (đệ quy là một khái niệm lập trình mà một chương trình sử dụng một phiên bản nhỏ hơn của nó). Ví dụ như Quicksort, một thuật toán gọn gàng dùng để sắp xếp các phần tử của một danh sách, có sử dụng đệ quy.

Nhưng đó không phải là định nghĩa duy nhất của nó. Trong lịch sử nó bắt nguồn từ 'divide and rule', một khái niệm để chỉ những người dân bản địa chiến đấu với nhau làm cho kẻ thù chung cai trị tất cả bọn họ. Hợp lại chúng ta thắng, chia rẽ chúng ta thất bại ...

Lý do mà tôi cho rằng divide and conquer là một trong những chiến lược đầy sức mạnh trong lập trình, đó là nó có thể được áp dụng ở mức cao : khi viết các chương trình phức tạp. Nếu bạn gặp một vấn đề quá khó để giải quyết trong một bước, bạn có thể sử dụng devide and conquer từng bước cho tới khi vấn đề của bạn trở nên dễ dàng. Sau đó bạn trở lại với vấn đề ở một cấp phía trên và tái sử dụng nó cho tới khi tất cả các vấn đề phụ được giải quyết và điều này đồng nghĩa với việc bạn đã giải quyết được vấn đề phức tạp ban đầu rồi đó.

Thậm chí khái niệm này còn được áp dụng để giải quyết tất cả các vấn đề ngoài lĩnh vực lập trình. Tôi chỉ cho bạn một ví dụ nhé : bạn cần sửa sang lại ngôi nhà? Quá khó để nắm được hết trong chốc lát, và tôi chắc rằng nếu không có kế hoạch cụ thể bạn sẽ bế tắc, thậm chí tuyệt vọng tới mức đốt luôn ngôi nhà của bạn lúc nào không hay. Không cần phải thế đâu, hãy chia nhỏ vấn đề ra và mọi thứ sẽ dễ dàng hơn :
  • cơ sở hạ tầng
    • hệ thống điện
    • đường dẫn khí ga
    • đường ống nước
    • hệ thống s
  • các căn phòng
    • phòng bếp
      • sửa trần
      • chuẩn bị tường
      • sàn gạch
      • bàn ăn
      • hộp tủ
    • phòng tắm
      • làm trần
        • đặt kính
        • vặn ốc vít
        • làm mượt
        • sơn
      • sưả tường
        • lát tường
        • lắp đặt vòi tắm
        • lắp cửa kính
    • phòng khách
    • phòng áp mái
    • tầng hầm
Tôi vừa mới liệt kê chi tiết vài hạng mục nhỏ, bạn không cần phải dừng lại ở bất kỳ cấp độ cụ thể nào, mà có thể chia càng nhỏ hạng mục tới mức bạn muốn. Đây là một bí quyết rất hữu ích, nó cho phép một người có thể giải quyết mọi vấn đề nếu cho anh ta đủ thời gian. Nó cũng áp dụng cho việc sữa chữa xe hơi, hệ thống điện, ...vân vân. Tôi chưa thấy một công việc nào mà 'divide and conquer' không làm cho nó đơn giản hơn và nó luôn làm tôi ngạc nhiên khi mọi người không biết về nó hay không biết làm thế nào để sử dụng nó trong thực tế. Và nếu bạn chia nhỏ công việc trước khi bắt tay vào làm thì hẳn nhiên nó đã trở thành một kế hoạch, mà nó sẽ càng dễ dàng hơn nếu bạn nhận ra trước được việc nào có thể sai hoặc thứ tự các việc cần làm trước, việc cần làm sau. Chẳng hạn như ở ví dụ trên, rõ ràng là bạn nên cần phải làm sàn của ngôi nhà trước khi làm các phụ kiện phòng bếp, nó giúp bạn tiết kiệm công sức và tiền của.
Rõ ràng là có vài trường hợp mà chiến lược này không dùng được. Nếu bạn có ước mong trèo lên đỉnh Everest một mình thì bạn sẽ khó mà hoàn thành được cho dù bạn đã chia nhỏ nó thành 2 quãng đường nhỏ hơn bằng toàn bộ hành trình. Bởi vì việc leo tới đỉnh Everest bản thân nó đã vượt ra khỏi giới hạn của một cá nhân con người. Nhưng gần như tất cả vấn đề bạn gặp hàng ngày, quy tắc này đảm bảo rằng bạn thường là có thể chia nhỏ chúng ra các vấn đề nhỏ hơn.

Vậy thì lần tới khi gặp phải vấn đề gì mà bạn không thể làm, trong lĩnh vực lập trình hay các vấn đề trong cuộc sống : Divide and conquer! Chia vấn đề thành hai phần nhỏ hơn bằng nhau nếu có thể, sau đó cố gắng giải quyết chúng và nếu chúng vẫn còn quá phức tạp thì hay lặp lại quá trình trên cho tới khi có ít nhất một vài phần của vấn đề lớn trở nên khả thi. Thậm chí đôi khi phải bỏ đi một phần nhỏ của vấn đề để làm cho công việc còn lại dễ giải quyết hơn.

Source : http://jacquesmattheij.com/divide-and-conquer

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 ...