Thursday, May 28, 2020

Cách cài đặt công cụ Podman trên CentOS 8

Bây giờ hỗ trợ chính thức cho thời gian chạy bộ chứa Docker đã bị loại bỏ bởi RHEL 8 / CentOS 8, quản trị viên container phải làm gì? May mắn thay, các nhà phát triển tại Red Hat đã làm việc trên libpod một thời gian. Libpod là thư viện quản lý container mới, bao gồm mọi thứ cần thiết để quản lý các pod, container và hình ảnh container.

Giải pháp mới đó được gọi là Podman có chức năng mà không yêu cầu trình nền chứa, vì tất cả các container và nhóm được tạo như các tiến trình con. Đối với tất cả những người đã dành hàng tuần, hàng tháng và hàng năm để tăng tốc với thời gian chạy docker, bạn không có gì phải lo sợ vì Podman CLI dựa trên docker CLI.

Tôi muốn hướng dẫn bạn các bước để cài đặt và sử dụng Podman trên CentOS 8.

Những gì bạn cần

Điều duy nhất bạn sẽ cần để thực hiện công việc này là:

  • Một phiên bản đang chạy của CentOS 8
  • Tài khoản người dùng có quyền sudo

Cách cài đặt Podman

Podman không có gói cài đặt riêng, vì nó là một phần của công cụ khác. Vì vậy, để có quyền truy cập vào Podman, hãy mở một cửa sổ đầu cuối trên máy chủ CentOS 8 của bạn và nhập lệnh:

sudo dnf install @container-tools -y

Quá trình cài đặt bắt đầu

Cách dùng Podman

Hãy để tôi chỉ cho bạn cách tương tự như Docker Podman. Ví dụ bạn muốn kéo một hình ảnh. Nếu bạn đã sử dụng lệnh kéo Docker, bạn sẽ nhận ra:

podman pull ubuntu

Để liệt kê các hình ảnh hiện có của bạn, hãy nhập lệnh:

podman images

Lệnh trên sẽ liệt kê tất cả các hình ảnh bạn đã kéo, cùng với ID hình ảnh.

Để xóa một hình ảnh, bạn có thể làm như vậy bằng ID hình ảnh, giống như bạn làm với thời gian chạy Docker. Nhập lệnh:

podman rmi ID

Trong đó ID là ID của hình ảnh sẽ bị xóa.

Bây giờ, giả sử bạn muốn triển khai một thùng chứa bằng hình ảnh Ubuntu mới tải xuống. Ta sẽ trình diễn một triển khai vùng chứa cực kỳ cơ bản, một triển khai sẽ chứa một container dựa trên hình ảnh Ubuntu và sau đó sử dụng lệnh echo từ bên trong container để in thông báo “Chào mừng bạn đến với Blogf4vnn.”

Để triển khai container này với Podman, nhập lệnh:

podman run --rm ubuntu /bin/echo "Welcome to Blogf4vnn."

Bạn gần như sẽ thấy ngay văn bản được in ra (Hình A).

Hình A

Cách cài đặt công cụ chứa Podman trên CentOS 8
Created with GIMP

Tất nhiên, container đó sẽ không giúp bạn nhiều. Hãy triển khai một container định tuyến cổng ngoài 8080 đến cổng bên trong 8080. Điều này có thể được thực hiện bằng lệnh:

sudo podman run -dit --name ubuntu-apache -p 8080:8080 ubuntu

Chúng ta phải chạy lệnh này với sudo vì các ràng buộc cổng chưa được hỗ trợ bởi các container không root.

Để liệt kê các container đang chạy của bạn, bạn sẽ phải một lần nữa, hãy sử dụng sudo như vậy:

sudo podman ps

Lệnh trên sẽ liệt kê các thùng chứa đang chạy của bạn (Hình B).

Hình B

Created with GIMP

Để dừng container đó, nhập lệnh:

sudo podman stop ID

Trong đó ID là tên của ID container.

Để xóa container hiện đã dừng, hãy nhập lệnh:

sudo podmand rm ID

Trong đó ID là tên của ID container.

Và đó là ý chính của việc cài đặt và sử dụng công cụ thời gian chạy container mới, Podman. Hãy theo dõi để biết thêm cách làm trung tâm xung quanh công nghệ mới này.

Share:

Tuesday, May 5, 2020

Top Mistakes That Back End Developers Make

It’s easy for developers to make mistakes, but we can prevent them if we know them beforehand.
In this article, we’ll look at mistakes that back end developers make.

Deploy on a Friday

If we don’t want to fix problems on the weekend, then we shouldn’t deploy on Friday.
Any deployment is risky and we should always think twice before doing if it’s not an emergency.
Things never go the way that we expect. And we definitely don’t want to ignore anything bad that comes up on the weekend and have angry customers to deal with on Monday.

Bad Input Validation

Server-side input validation is important. They serve 2 purposes. We need them to ensure security and also to prevent corrupt data from being saved.
We have to prevent SQL injection issues so that attackers can’t run malicious code to do whatever they want in our databases.
Also, we should validate input data to make sure that the data is in the proper format that we’re looking for.
If we don’t, then we’ll probably run into problems in some other places.
Most back end frameworks should be able to do both out of the box so that we don’t have to write all the code from scratch to do all that validation.

Authentication and Authorization

Authentication and authorization are 2 different things. People may not be aware of that.
Authentication is just checking for the ability to be able to log into a system with valid credentials. Authorization is the privileges that we give users.
We should make sure that users aren’t authorized to do more than they should.
For instance, if they’re a regular user, then they shouldn’t be able to view other user’s private profile. That’s an authorization.
Authentication is just making sure that a username and password or anything else that we have to enter is valid so that we can log into a system.

Ignoring Performance and Scaling

Performance and scaling are always important things to consider in the back end. We don’t want our systems to time out when we’re dealing with too much data.
Therefore, we should consider caching, doing long-running jobs in the background, pagination, etc. These are things that’ll help us prevent overloading our servers.
It’s bad if our app is overloaded since it’ll fail before it can do what customers want.

Not Running Resource-Intensive Processes in the Background

Resource intensive jobs like report generation, sending mass emails, etc. should all be done in the background. They’re all resource-intensive and it’s hard to do them synchronously without holding up our app for a long time.
Users will be frustrated if they’re left waiting for a long time when we have jobs running in the foreground and keeping users waiting.
Therefore, we should create background jobs for these resource-intensive tasks and batch them so that they won’t overload our servers.
Also, we should move these tasks to run on their own servers so it won’t overwhelm the main app.

Not Optimizing Bandwidth Usage

We should minimize bandwidth usage in all communications. For instance, we may be sending large chunks of data or images between multiple remote servers.
To make the transfer process more efficient, we should compress everything before sending it to save bandwidth. Then they can be decompressed on the receiving server.

Using RESTful Anti-Patterns

REST API should follow some basic best practices. For instance, the HTTP verbs to match the database operations that they’re doing.
GET should retrieve data, POST should create data, PUT and PATCH should update data, and DELETE should delete data.
This way, no one will be confused as to what our code is doing.
Also, our endpoints have to send the right HTTP status codes. 200 series is for successful operations. 400 series for errors coming from client-side and 500 series errors for errors occurring on the server-side.
For instance, 401 is for unauthorized, 403 means that we’re forbidden to access a resource because of a lack of privileges, 404 for not found, 502 for timeout errors.

Conclusion

We should stop ourselves before committing these mistakes if we’re doing back end development.
We should think about performance, scaling, validating inputs, and returning errors with the right status code.
Share:

Chuyện bên lề của dev










Bạn đi đến đâu, bạn làm điều gì, thì cũng đang phải tuân theo những nguyên tắc, điều lệ cho dù bạn có biết hay không biết về sự tồn tại của nó. Vậy đâu là những nguyên tắc của developer?
Duới đây là nhìn nhận cá nhân, rút ra dựa trên kinh nghiệm bản thân, bài học mà cái giá của nó không hề rẻ. Xin nhắc lại, những nguyên tắc dưới đây mang góc độ chủ quan.




Công nghệ là công cụ, không phải giải pháp

Bạn có thể học những framework mới nhất, công cụ xịn nhất, nhưng tất cả những thứ đó không phải là giải pháp cho các vấn đề mà chúng ta cần giải quyết, chúng chỉ đơn giản là các công cụ giúp bạn giải quyết các vấn đề.
Bạn cần cẩn thận, tránh tình trạng cuồng một công nghệ nào đó, hoặc say đắm các công nghệ đang hot. Nhưng không có nghĩa là bạn lại không thành thạo một công nghệ nào cả !

Thông minh là kẻ thù của sự đơn giản, dễ hiểu

Thường những developer muốn thể hiện sự thông minh của mình qua những đoạn code rẩt khó hiểu, code rất ngắn, code với những funciton, hay cú pháp rất rất lạ. Nên nhớ một điều rằng, code của bạn tốt, khi bạn và những đồng nghiệp của bạn, hay đơn giản là những thằng nhóc mới học lập trình đọc cũng có thể hiểu được code của bạn đang viết gì. Ở đây mình chưa xét đến perform nhé.
Và thường thì những developer thường có suy nghĩ tốt hơn những ngưởi khác, những khách hàng thực sự sử dụng những sản phẩm mà họ làm ra, vậy hãy đặt mình dưới vai trò của 1 người dùng không biết tí gì về code cả, mà thiết kế giao diện sao cho phù hợp nhé.

Chỉ viết code khi bạn cần phải viết

Nghe vô lý, nhưng lại rất hợp lý. Bạn đã nghe câu "Code của bạn không thể có bug, nếu bạn không viết code", sự thực thì, khá gần đúng như vậy, code càng nhiều, khả năng gây lỗi, gây bug càng cao. Vậy không phải lúc nào cũng code. Hãy cẩn trọng suy nghĩ trước khi viết 1 dòng code.
Software developer giỏi không viết code trừ khi họ thấy cần thiết. Software developer tầm cỡ cố gắng xóa nhiều code nhất họ có thể.

Luôn luôn nắm rõ code của bạn sẽ làm gì trước khi viết nó

Nghe khá ngược, đương nhiên là mình viết ra code thì phải biết nó làm gì chứ nhỉ. "Nắm rõ code của bạn làm gì ở đây", ý mình là đoạn code của mình sẽ thực hiện chức năng gì, nó có đúng với yêu cầu của khách hàng không. Thường thì phần lớn các bạn code mà không thực sự hiểu khách hàng muốn gì. Vì vậy, hãy chắc chắn rằng mình đã hiểu thực sự ý của khách hàng trước khi code 1 cái gì đó.

Đừng bao giờ quên TEST code của mình

Đừng bao giờ để bản thân "dậm chân tại chỗ"

Tại sao lại thế, như bạn đã biết sâu xa hơn thì là quy luật triết học, bạn đứng yên trong khi người khác phát triển, thì đó chính là bạn đã thụt lùi. Nhất là đối với ngành IT này, công nghệ cập nhật thay đổi từng giờ, vì vậy, hãy đừng để mình lạc hậu nha

Bạn không thể biết mọi thứ

Có 1 điều khá thú vị là bạn càng biết nhiều, bạn càng có nhiều kiến thức, bạn lại cảm thấy mình càng chẳng biết gì cả. Vì vậy, đừng nản lòng khi bạn không biết 1 thứ gì đó, đừng bao giờ ngại hỏi han đồng nghiệp, bạn bè, về những cái mình chưa biết.
---Nguồn: st

Share:

Tuesday, March 24, 2020

Hoa Sơn Luận code

Thần Code Sơn Trang, mười năm đã trôi qua
Tuyết bay trắng trời, gió thổi vi vu như cắt da cắt thịt. Cả 1 vùng tuyết sơn chìm trong sắc trắng, không khí lạnh lẽo thê lương
Một người đại hán tuổi chừng ba mươi, đang ngồi lặng lẽ bên máy tính, song thủ gõ phím lách cách, mục quang sáng ngời đang chăm chăm nhìn màn hình.
Thiếu chủ, đã canh hai rồi, sao người chưa đi ngủ
Một lão nô đầu tóc bạc trắng, tay bưng tách trà dâng lên

Người đại hán nó chính là Dương Cú Đơ, thiếu chủ của Thần Code Sơn Trang. 
Mười năm qua, từ ngày được Hắc Y Nhân truyền cho Coding thập tam thức trong cuốn Clean Code. Ta ngày đêm nghiên cứu thực hành, luyện tập trên cả codefight, hacker rank. Thời gian thoi đưa, đến giờ cũng đã làu thông, level của ta trên codefight cũng đạt hàng top rồi. Nhưng sao ta vẫn không thể ngộ hết được bí kíp này, không sao đạt được cảnh giới code lưu hỏa thuần thanh.
Thiếu chủ, ngài tuy luyện Clean Code trong mười năm, nhưng chủ yếu là bế quan ở Thần Code Sơn Trang này, không làm dự án thật, không tiếp xúc với các cao thủ coding trong thiên hạ. Khác gì có học mà chẳng có hành, kiếm báu đem ra bổ củi. Đâu thể đạt được đến mức coding guru, xuất thần nhập hóa được.Tôi nghe nói ở Thăng Long thành, cứ 5 năm một lần, có tổ chức “Hoa Sơn Luận Code” coding contest nơi người chơi ra tay viết code, diệt “bug”, đả bại testcase, từ đó phân định thiên-hạ-đệ-nhất lập trình, nơi các anh hùng coding trong thiên hạ tụ về, so tài cao thấp để tìm ra coding minh chủ. Sao thiếu chủ không đến đó thi triển tài năng, biết đâu không vang danh thiên hạ, lấy lại thanh danh cho Thần Code Sơn Trang chúng ta.
Dương Cú Đơ nghe xong như tỉnh cơn mê, nghĩ thầm
Hoa Sơn Luận Code, biết đâu ta sẽ tìm được cựu thù đã sát hại cả nhà ta năm xưa. Đúng là cơ hội tốt
Thiếu chủ, xưa kia lão trang chủ uy chấn giang hồ không chỉ là nhờ tài code đạo mà còn cò món bảo vật trấn trang được cất giấu bí mật. Nay thiếu chủ đang trưởng thành, lão nô xin trao lại cho người
Đây là vũ khí đứng đầu trong binh khí phổ, tên là Ô Nha Thử (black Mouse) và Ngọc Tịnh Bàn (Keyboard). Ngày xưa những kẻ

Share:

Devops ký sự (Phần 3)

Lại nói chuyện hồi trước, SRE team được thành lập, gọi là Site Reliability Engineer, là kỹ sư quản lý hệ thống, đảm bảo hệ thống làm việc trơn tru, không trục trặc, ứng phó với các sự cố xảy ra. Đồng thời xử lý những request liên quan đến hệ thống đến từ các team khác.

Theo định nghĩa của Google thì SRE là kĩ sư phần mềm nhưng làm công việc liên quan đến operation là chính. Công việc này chiếm khoảng 50%, chủ yếu là xử lý issue, on-call. 50% còn lại tập trung phát triển tính năng cho hệ thống như auto-scaling, self-healing… 
Như vậy SRE engineer đòi hỏi kĩ năng administration (Ops) cũng như khả năng development (Dev). Cho nên kĩ sư SRE và DevOps có nhiều điểm tương đồng. Tuy hai mà một, tuy một mà hai
Nghe nói ở Fsoft cũng có 1 team như vậy tính ra cũng được 10 nhân mạng, trên thông cloud (aws, gce, azure) dưới tường viết code (python, shellscript). Certification , bằng cấp đầy người (nhẹ nhẹ thì aws architect, sơ sơ thì gce developer engineer)
Team SRE thì quan trọng nhất là Runbook, có thể hiểu nó như là Cửu Âm Chân Kinh của Quánh Tĩnh, Di Thư Võ mộc của Nhạc Phi. Là tập hợp hướng dẫn từng bước cách xử lý sự cố , hay vận hành hệ thống, được viết kĩ lưỡng, tổ chức khoa học để cho các kĩ sư SRE tham khảo.
Runbook được tạo thành khi các kĩ sư SRE làm việc, troubleshooting, và ghi lại kinh nghiệm của họ vào Runbooks. Lâu dần tích tiểu thành đại, mà runbooks trở thành pho bí kíp, đặc biệt hữu ích cho các kỹ sư SRE mới.
Hận thay, việc của SRE engineer cũng như làm dâu trăm họ. Một ngày số request xử lý tính đến cả trăm, trăm dâu lại đổ đầu tằm. Gặp những người quân tử hào kiệt thì cảm thông, nhưng nếu gặp phải kẻ bụng dạ đàn bà, tiểu nhân hẹp hòi thì thật oán hận không kể xiết. Lúc tạo request thì hò hét giục giã liên hồi. Lúc làm xong thì bặt vô âm tín, chẳng một lời cảm ơn, công lao không ai nhắc đến. Đấy còn là công việc trơn tru, rủi thay có lúc xử lý không kịp trễ nải là lập tức bị báo cáo report.
Đấy nói chuyện hồi trước có chú kĩ sư mới vào kinh nghiệm còn non nên lỡ tay Server Reboot, để team mang tiếng xấu là Server Reboot Engineer. Âu cũng là trẻ người non dạ, nên mới bước sa cơ lỡ tay đánh máy.
Chuyện vài tháng đã trôi qua, tưởng chìm vào quên lãng thì ngờ đâu họa vô đơn chí, phúc bất trùng lai. Anh SRE truy cập vào database mongodb của server với quyền admin. Thực chất chỉ là check lại dữ liệu, nào ngờ trong lúc xuất kì bất ý, có lẽ là do tâm trạng đang xốn xang vì corona virus, mà song thủ ra 1 chiêu hiểm độc
db.users.drop()
1 lệnh bay ra như mũi tên bắn khỏi dây cung, làm sao lấy lại được. Vây là toàn users data bay luôn trong vòng 1 nốt nhạc. Anh kĩ sư mặt như chàm đổ, không rét mà run, toàn thân lạnh toát. Chuyện xảy ra vào giờ Ngọ, vào lúc ban trưa, mọi người đang ăn cơm nghỉ ngơi.
Hoảng hồn báo vội cho Team Lead để vào cuộc xử lý sự cố. Tuy nhiên các hệ thống lớn luôn luôn có cơ chế disaster recovery. Các database server trên aws luôn được thiết lập chế độ multi-AZ kèm snapshot theo chu kì. Ngoài ra trên server mongo còn có cron job chạy autoback up

# cat /etc/crontab

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  | .---------- day of month (1 - 31)
# |  | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  | | |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  | | |  |
# *  * * *  * user-name  command to be executed

# START managed zone: mongo backup -DO-NOT-EDIT-
# dump mongo once a day for dev/qa/uat env at 8pm EST
10 1 * * * root /data/bin/database_backup.py 7 > /tmp/log.out 2>&1
# END managed zone: mongo backup --
Ngoài ra còn có 1 server backup dạng master lưu tất cả các bản backup của database, nên khi có sự cố chỉ việc chạy lệnh phục hồi. Hệ thống lớn như vậy lẽ nào dễ sụp đổ??
Server mongodb này được build dưới dạng cluster, gồm 1 primary database và nhiều read replicas
Cho nên chỉ trong vòng 30 phút, bản backup đã được tìm thấy trong server backup. Runbooks phục hồi hệ thống cũng đã sẵn sàng. Sau khi check database này không sử dụng kĩ thuật sharding
rs0:PRIMARY> db.printShardingStatus()
printShardingStatus: this db does not have sharding enabled. be sure you are connecting to a mongos from the shell and not to a mongod.
rs0:PRIMARY>
Nếu không thì phải làm như vầy
Sau khi test thử data trong local chạy ổn định, anh kĩ sư trong sử ra 1 chiêu database restore 
/opt/mongo/bin/mongorestore  --ssl --host $HOSTNAME:27017 --db users <folder backup>/users
Data đã phục hồi chỉ trong 1 nốt nhạc, không ảnh hưởng lớn đến công việc.
Nhưng hận thay lúc gian nan, hoạn nạn mới biết con người. Internal chưa kịp xử lý thì external đã có kẻ báo cáo lên trên. Ấy gọi là lúc có công thì cho người khác hưởng, nhưng lúc hiểm nguy là phải gánh mọi tội tình. Âu cũng là mình làm mình chịu, giang hồ hiểm ác, lòng người thâm sâu nào thể trách ai
Share: