server

مقدمه
Velero يك ابزار پشتيبان مناسب براي خوشه هاي Kubernetes است كه موارد Kubernetes را براي ذخيره سازي مورد به مورد، فشرده سازي و پشتيبان گيري مي كند. همچنين با استفاده از ويژگي هاي اسنپ شات ذخيره سازي واحد ارائه دهنده cloud ، عكس هايي از واليوم هاي مداوم خوشه شما مي گيرد و مي تواند موارد و واليوم هاي ماندگار خوشه را به حالت قبلي بازگرداند.
افزونه vpsgol Velero به شما امكان مي دهد تا از حافظه بلوك vpsgol استفاده كنيد تا از واليوم هاي ماندگار اسنپ شات بگيريد و فضايي به شما ميدهد تا از موارد Kubernetes بك آپ تهيه كنيد. در هنگام اجراي يك خوشه Kubernetes در vpsgol ، اين به شما امكان مي دهد تا به سرعت از وضعيت خوشه خود نسخه پشتيبان تهيه كرده و در صورت بروز مشكل بازيابي كنيد.
در اين آموزش ابزار خط فرمان velero را روي يك دستگاه محلي تنظيم و پيكربندي مي كنيم و مؤلفه سرور مجازي را در خوشه Kubernetes خود مستقر مي كنيم. سپس يك نمونه از برنامه Nginx را استفاده مي كنيم كه از يك واليوم پايدار براي ورود به سيستم استفاده مي كند و سپس يك سناريوي بازيابي مشكل را شبيه سازي مي كند.
پيش نيازها
قبل از شروع اين آموزش ، موارد زير را بايد در اختيار داشته باشيد:
در رايانه محلي خود:
⦁ ابزار خط فرمان kubectl ، پيكربندي شده بايد تا به خوشه شما متصل شود. مي توانيد اطلاعات بيشتري در مورد نصب و پيكربندي ر در مطالب Kubernetes بخوانيد.
⦁ ابزار خط فرمان gitكه مي توانيد نحوه نصب git را در شروع با Git بياموزيد.
در حساب vpsgol خود:
⦁ يك خوشه vpsgol Kubernetes يا يك خوشه Kubernetes (نسخه 1.7.5 يا بالاتر) در دراپلت هاي vpsgol.
⦁ سرور DNS كه در داخل خوشه شما قرار دارد. اگر از vpsgol Kubernetes استفاده مي كنيد ، اين به طور پيش فرض اجرا مي شود. براي كسب اطلاعات بيشتر در مورد پيكربندي يك سرويس DNS Kubernetes ، از ⦁ Customizing DNS Service در مطالب رسمي Kuberentes كمك بگيريد.
⦁ فضاي vpsgol كه موارد پشتيبان گرفته شده Kubernetes شما را ذخيره مي كند. براي يادگيري نحوه ايجاد يك فضا ، از  ⦁ the Spaces product documentation كمك بگيريد.
⦁ يك جفت كليد دسترسي براي vpsgol Space. براي يادگيري نحوه ايجاد مجموعه اي از كليدهاي دستيابي ، از ⦁ How to Manage Administrative Access to Spaces كمك بگيريد.
⦁ يك نشانه دسترسي شخصي براي استفاده با vpsgol API. براي يادگيري نحوه ايجاد يك نشانه دسترسي شخصي ، از ⦁ How to Manage Administrative Access to Spaces كمك بگيريد. اطمينان حاصل كنيد كه توكن ايجاد شده يا استفاده شده از مجوزهاي خواندن / نوشتن و يا اسنپ شات استفاده نميكند.
پس از تنظيم همه اين موارد ، آماده شروع كار با اين راهنما هستيد.

مرحله 1 – نصب مشتري Velero
ابزار پشتيبان گيري Velero شامل يك مشتري نصب شده بر روي رايانه محلي شما و يك سرور مجازي است كه در خوشه Kubernetes شما اجرا مي شود. براي شروع ، مشتري محلي Velero را نصب خواهيم كرد.
در مرورگر وب خود ، به صفحه منتشر شده repo Velero GitHub برويد ، نسخه مربوط به سيستم عامل و معماري سيستم خود را پيدا كنيد و آدرس پيوند را كپي كنيد. براي اهداف اين راهنما ، ما از يك سرور مجازي اوبونتو 18.04 در يك پردازنده x86-64 (يا AMD64) به عنوان دستگاه محلي خود و نسخه Velero v1.2.0 استفاده خواهيم كرد.
توجه: براي دنبال كردن اين راهنما ، بايد v1.2.0 از مشتري Velero را دانلود و نصب كنيد.
سپس ، از خط فرمان روي رايانه محلي خود ، به دايركتوري موقت / tmp برويد و cd را در آن قرار دهيد:
$cd / tmp
از wget و پيوندي كه قبلاً كپي كرده ايد براي دانلود تاربال نسخه استفاده كنيد:
$wget https: // link_copied_from_release_page
پس از اتمام دانلود ، تاربال را با استفاده از tar اكستركت كنيد (توجه داشته باشيد كه نام فايل بسته به نسخه منتشر شده و سيستم عامل شما ممكن است متفاوت باشد):
$tar -xvzf velero-v1.2.0-linux-amd64.tar.gz
ديركتوري / tmp اكنون بايد ديركتوري اكستركت شده velero-v1.2.0-linux-amd64 و همچنين تاربلي كه اخيراً دانلود كرده ايد ، را شامل شود.
تأييد كنيد كه مي توانيد مشتري velero را با اجراي باينري راه اندازي كنيد:
$./velero-v1.2.0-linux-amd64/velero help
شما بايد خروجي راهنمايي زير را مشاهده كنيد:
Output
Velero is a tool for managing disaster recovery, specifically for Kubernetes
cluster resources. It provides a simple, configurable, and operationally robust
way to back up your application state and associated data.

If you’re familiar with kubectl, Velero supports a similar model, allowing you to
execute commands such as ‘velero get backup’ and ‘velero create schedule’. The same
operations can also be performed as ‘velero backup get’ and ‘velero schedule create’.

Usage:
velero [command]

Available Commands:
backup Work with backups
backup-location Work with backup storage locations
bug Report a Velero bug
client Velero client related commands
completion Output shell completion code for the specified shell (bash or zsh)
create Create velero resources
delete Delete velero resources
describe Describe velero resources
get Get velero resources
help Help about any command
install Install Velero
plugin Work with plugins
restic Work with restic
restore Work with restores
schedule Work with schedules
snapshot-location Work with snapshot locations
version Print the velero version and associated image
. . .

در اين مرحله بايد velero  قابل اجرا را از ديركتوري موقت tmp  خارج كنيد و آن را به PATH اضافه كنيد. براي افزودن آن به PATH روي يك سيستم اوبونتو كافيست آن را در /usr/local/bin كپي كنيد:
$sudo mv velero-v1.2.0-linux-amd64/velero /usr/local/bin/velero
مرحله 2 – پيكربندي اطلاعات سري
قبل از تنظيم مؤلفه سرور مجازي Velero ، بايد كليدهاي vpsgol Spaces و نشانه هاي API خود را آماده كنيد. مجدداً با استفاده از دستور cd به ديركتوري موقت / tmp برويد:
$ cd / tmp
اكنون يك نسخه از افزونه Velero را براي vpsgol دانلود خواهيم كرد. به صفحه انتشار نسخه هاي Github افزونه برويد و پيوندهايي كه به.tar.gz ختم ميشوند را كپي كنيد.
از wget و پيوندي كه قبلاً كپي كرده ايد براي دانلود تاربال نسخه استفاده كنيد:
$wget https: // link_copied_from_release_page
پس از اتمام دانلود ، تاربل را با استفاده از tar اكستركت كنيد (دوباره توجه داشته باشيد كه نام فايل بسته به نسخه منتشر شده ممكن است متفاوت باشد):
$tar -xvzf v1.0.0.tar.gz
ديركتوري / tmp اكنون بايد پوشه velero-plugin-1.0.0 اكستركت شده و همچنين تاربل كه اخيراً دانلود كرده ايد ، را شامل شود.
سپس cd را در دايركتوري velero-plugin-1.0.0 وارد ميكنيم:
$ cd velero-plugin-1.0.0
اكنون مي توانيم كليدهاي دسترسي را براي vpsgol Space و نشانه API براي استفاده به عنوان Kubernetes Secret ذخيره كنيم. ابتدا با استفاده از ويرايشگر مورد علاقه خود ، فايل examples/cloud-credentials را باز كنيد.
⦁ $ nano examples/cloud-credential
پرونده به شرح زير خواهد بود:
/tmp/velero-plugin-1.0.0/examples/cloud-credentials
[default]
aws_access_key_id=
aws_secret_access_key=

براي استفاده از كليدهاي vpsgol Spaces ، “متغيرهاي” و را ويرايش كنيد. حتماً كاراكترهاي < و > را حذف كنيد.
مرحله بعدي ويرايش فايل 01-velero-secret.patch.yaml است به گونه اي كه شامل نشانه API vpsgol شما باشد. پرونده را در ويرايشگر مورد علاقه خود باز كنيد:

⦁ $ nano examples/01-velero-secret.patch.yaml
⦁
مي بايست شبيه به اين باشه:
—
apiVersion: v1
kind: Secret
stringData:
vpsgol_token:
type: Opaque

براي استفاده از ، كل مكان نگهدار را تغيير دهيد. خط بايد چيزي شبيه به vpsgol_token: 18a0d730c0e0…. باشد: باز هم ، حتماً كاراكترهاي < و > را حذف كنيد.
مرحله 3 – نصب سرور مجازي Velero
نصب Velero شامل تعدادي از موارد Kubernetes است كه همگي براي ايجاد ، برنامه ريزي و مديريت پشتيبان گيري با هم كار مي كنند. velero قابل اجرا كه به تازگي دانلود كرده ايد مي تواند اين موارد را براي شما توليد و نصب كند. دستور نصب velero مراحل آماده سازي اوليه را انجام مي دهد تا براي خوشه شما پشتيبان تهيه شود. به طور خاص:
⦁ يك نام فضا velero ايجاد ميكند.
⦁ حساب سرويس velero را اضافه ميكند.
⦁ قوانين كنترل دسترسي مبتني بر نقش (RBAC) را براي اعطاي مجوز به حساب سرويس velero پيكربندي ميكند.
⦁ تعريف منابع اختصاصي (CRD) را براي منابع خاص Velero نصب ميكند: پشتيبان گيري ، برنامه ريزي، بازيابي ، پيكربندي.
⦁ پلاگين هاي Velero را براي مديريت اسنپ شات و فضاي ذخيره سازي ثبت ميكند.
دستور velero install را با چند گزينه تنظيمات غير پيش فرض اجرا خواهيم كرد. به طور خاص ، شما نياز به ويرايش هر يك از تنظيمات زير در فراخواني واقعي فرمان براي مطابقت با پيكربندي Spaces داريد:
– backup velero-backup: مقدار velero-backups را تغيير دهيد تا با نام فضاي vpsgol Space شما مطابقت داشته باشد. به عنوان مثال اگر فضاي خود را ” backup-bucket ” ناميديد ، اين گزينه به اين شكل است: –bucket backup-bucket
–backup-location-config s3Url=https://nyc3.vpsgolspaces.com,region=nyc3 : URL و منطقه را تغيير دهيد تا مطابق با تنظيمات فضاي شما باشد. به طور خاص ، هر دو بخش nyc3 را ويرايش كنيد تا با منطقه اي كه فضاي شما در آن ميزبان است مطابقت داشته باشد. به عنوان مثال ، اگر فضاي شما در منطقه fra1 ميزباني شود ، اين خط به اين صورت است: –backup-location-config s3Url=https://fra1.vpsgolspaces.com,region=fra1 region=fra1.
شناسه هاي منطقه عبارتند از: nyc3 ، sfo2 ، sgp1 و fra1.
پس از آماده شدن با تنظيمات مناسب مكان bucket و backup ، وقت آن است كه Velero را نصب كنيد. دستور زير را اجرا كنيد ، و در صورت لزوم مقادير خود را جايگزين كنيد:

$velero install
$  –provider velero.io/aws
$ –backup velero backup
$ –plugins velero/velero-plugin-for-aws:v1.0.0,vpsgol/velero-plugin:v1.0.0
$ –backup-location-config s3Url=https://nyc3.vpsgolspaces.com,region=nyc3
$ –use-volume-snapshots=false
$ –secret-file=./examples/cloud-credentials
بايد خروجي زير را مشاهده كنيد:
Output
CustomResourceDefinition/backups.velero.io: attempting to create resource
CustomResourceDefinition/backups.velero.io: created
CustomResourceDefinition/backupstoragelocations.velero.io: attempting to create resource
CustomResourceDefinition/backupstoragelocations.velero.io: created
CustomResourceDefinition/deletebackuprequests.velero.io: attempting to create resource
CustomResourceDefinition/deletebackuprequests.velero.io: created
CustomResourceDefinition/downloadrequests.velero.io: attempting to create resource
CustomResourceDefinition/downloadrequests.velero.io: created
CustomResourceDefinition/podvolumebackups.velero.io: attempting to create resource
CustomResourceDefinition/podvolumebackups.velero.io: created
CustomResourceDefinition/podvolumerestores.velero.io: attempting to create resource
CustomResourceDefinition/podvolumerestores.velero.io: created
CustomResourceDefinition/resticrepositories.velero.io: attempting to create resource
CustomResourceDefinition/resticrepositories.velero.io: created
CustomResourceDefinition/restores.velero.io: attempting to create resource
CustomResourceDefinition/restores.velero.io: created
CustomResourceDefinition/schedules.velero.io: attempting to create resource
CustomResourceDefinition/schedules.velero.io: created
CustomResourceDefinition/serverstatusrequests.velero.io: attempting to create resource
CustomResourceDefinition/serverstatusrequests.velero.io: created
CustomResourceDefinition/volumesnapshotlocations.velero.io: attempting to create resource
CustomResourceDefinition/volumesnapshotlocations.velero.io: created
Waiting for resources to be ready in cluster…
Namespace/velero: attempting to create resource
Namespace/velero: created
ClusterRoleBinding/velero: attempting to create resource
ClusterRoleBinding/velero: created
ServiceAccount/velero: attempting to create resource
ServiceAccount/velero: created
Secret/cloud-credentials: attempting to create resource
Secret/cloud-credentials: created
BackupStorageLocation/default: attempting to create resource
BackupStorageLocation/default: created
Deployment/velero: attempting to create resource
Deployment/velero: created
Velero is installed! ⛵ Use ‘kubectl logs deployment/velero -n velero’ to view the status.

شما ميتوانيد به كارگيري ورودي ها با استفاده از دستور kubect از خروجي را مشاهده كنيد. پس از آماده سازي به كارگيري، ميتوانيد به مرحله بعدي برويد كه پيكربندي سرور مجازي است. به كارگيري موفق شبيه زير خواهد بود (با يك تفاوت ستون AGE):
$ kubectl get deployment/velero –namespace velero
Output
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 2m

دراين نقطه مولفه سرور مجازي Velero  را در خوشه Kubernetes  به عنوان يك صف آرايي نصب كرده ايد. همچنين كليدهاي فضا را با Velero  و با استفاده از Kubernetes Secret ثبت نموده ايد.

توجه: مي توانيد kubeconfig را كه ابزار خط فرمان velero بايد با فلگ –kubeconfig استفاده كند ، مشخص كنيد. اگر از اين فلگ استفاده نمي كنيد ، velero متغير محيط KUBECONFIG را بررسي كرده و سپس به پيش فرض kubectl  يعني (~/.kube/config) برميگردد.

مرحله 4 – پيكربندي اسنپ شات
هنگامي كه سرور مجازي Velero را نصب كرديم ، گزينه –use-volume-snapshots = false بخشي از دستور بود. از آنجا كه مي خواهيم اسنپ شات از دستگاه هاي ذخيره سازي بلوك موجود در خوشه Kubernetes بگيريم ، بايد به Velero بگوييم كه از پلاگين صحيح براي ذخيره سازي بلوك vpsgol استفاده كند.
دستور زير را اجرا كنيد تا افزونه فعال شود و آن را به عنوان ارائه دهنده اسنپ شات پيش فرض ثبت كنيد:

$velero snapshot-location create default –provider vpsgol.com/velero
خروجي زير را مشاهده خواهيد كرد:
Snapshot volume location “default” configured successfully.

مرحله 5 – اضافه كردن يك نشانه API
در مرحله قبل ، ذخيره بلوك و موارد دخيره را در سرور مجازي Velero ايجاد كرديم. ما افزونه vpsgol / velero: v1.0.0 را با سرور مجازي ثبت كرده ايم و كليدهاي مخفي Spaces را در خوشه نصب كرده ايم.
مرحله آخر افزودن اطلاعات سري cloud-credentials است كه قبلاً براي استفاده از نشانه vpsgol API ما ايجاد كرده ايم. بدون اين نشانه ، افزونه Snapshot قادر به تأييد اعتبار با API vpsgol نخواهد بود.
ما مي توانيم از دستور edit kubectl براي تغيير موضوع آرايش Velero با استفاده از نشانه API استفاده كنيم. با اين حال ، ويرايش موضوعات پيچيده YAML با دست مي تواند خسته كننده و پر خطا باشد. در عوض ، از دستور patch kubectl استفاده خواهيم كرد زيرا Kubernetes از patch موضوعات پشتيباني مي كند. بياييد نگاهي گذرا به مطالب فايل هاي پچ مورد نظر خود بياندازيم.
اولين فايل افزوده examples/01-velero-secret.patch.yaml است كه قبلاً ويرايش كرده ايد. اين براي افزودن نشانه API شما به اطلاعات سري secrets/cloud-credentials طراحي شده است كه از قبل حاوي كليدهاي Spaces شما بود. فايل را cat كنيد:
$cat examples/01-velero-secret.patch.yaml
بايد مانند اين باشد (با نشان شما به جاي نگهدارنده  placeholder):
examples/01-velero-secret.patch.yaml
. . .
—
apiVersion: v1
kind: Secret
stringData:
vpsgol_token:
type: Opaque

حال بياييد به فايل پچ Deployment نگاه كنيم:
$cat examples/02-velero-deployment.patch.yaml
بايد YAML زير را ببينيد:
examples/02-velero-deployment.patch.yaml
. . .
—
apiVersion: v1
kind: Deployment
spec:
template:
spec:
containers:
– args:
– server
command:
– /velero
env:
– name: vpsgol_TOKEN
valueFrom:
secretKeyRef:
key: vpsgol_token
name: cloud-credentials
name: velero

اين فايل نشان مي دهد كه ما در حال وصله كردن Deployment’s Pod spec هستيم كه به آن velero گفته مي شود. از آنجا كه اين يك پچ است ، ديگر نيازي به مشخص كردن كل خصوصيات يا ابرداده هاي Kubernetes نيست. در اين حالت ، پياده سازي Velero قبلاً با استفاده از cloud-credentials پيكربندي شده است زيرا دستور نصب velero آن را براي ما ايجاد كرده است. بنابراين ، تمام آنچه كه بايد اين پچ انجام دهد ثبت نام vpsgol_token به عنوان متغير محيط با Velero Pod است كه قبلاً مستقر شده است.
بياييد اولين پچ مخفي را با استفاده از دستور patch kubectl اعمال كنيم:

$kubectl patch secret/cloud-credentials -p “$(cat examples/01-velero-secret.patch.yaml)” –namespace velero
بايد خروجي زير را مشاهده كنيد:
secret/cloud-credentials patched

سرانجام ما Deployment را پچ مي كنيم. دستور زير را اجرا كنيد:
$kubectl patch deployment/velero -p “$(cat examples/02-velero-deployment.patch.yaml”) –namespace velero
در صورت موفقيت آميز بودن، خروجي زير را مشاهده خواهيد كرد:
deployment.apps/velero patched

بياييد تأييد كنيم كه آرايش پچ شده با استفاده از kubectl get در فضايvelero كار مي كند:
$kubectl get deployment/velero –namespace velero
بايد خروجي زير را مشاهده كنيد:
NAME READY UP-TO-DATE AVAILABLE AGE
velero 1/1 1 1 12s

در اين مرحله Velero در حال اجرا و كاملاً پيكربندي شده است ، و آماده تهيه نسخه پشتيبان و بازيابي موارد خوشه اي Kubernetes و واليوم هاي پايدار در vpsgol Spaces و Block Storage است.
در بخش بعدي ، ما يك آزمايش سريع انجام خواهيم داد تا اطمينان حاصل كنيم كه عملكرد نسخه پشتيبان و بازيابي همانطور كه انتظار مي رود ، كار مي كند.
مرحله ششم – تست تهيه نسخه پشتيبان و بازيابي فرآيند
اكنون كه Velero را با موفقيت نصب و پيكربندي كرده ايم ، مي توانيم با استفاده از واليوم و سرويس مداوم ، آزمايش Nginx Deployment را ايجاد كنيم. پس از اجراي Deployment ، از پشتيبان گيري استفاده مي كنيم و فرآيند را بازيابي مي كنيم تا اطمينان حاصل شود كه Velero پيكربندي شده و به درستي كار مي كند.
اطمينان حاصل كنيد كه هنوز در دايركتوري /tmp/velero-plugin-1.0.0 كار مي كنيد. دايركتوري examples  حاوي نمونه Nginx به نام nginx-shembull.yaml است.
اين فايل را با استفاده از ويرايشگر مورد نظر خود باز كنيد:
$nano examples/nginx-example.yaml
متن زير را بايد مشاهده كنيد:
Output
. . .
—
apiVersion: v1
kind: Namespace
metadata:
name: nginx-example
labels:
app: nginx

—
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: nginx-logs
namespace: nginx-example
labels:
app: nginx
spec:
storageClassName: do-block-storage
accessModes:
– ReadWriteOnce
resources:
requests:
storage: 5Gi

—
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: nginx-example
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes:
– name: nginx-logs
persistentVolumeClaim:
claimName: nginx-logs
containers:
– image: nginx:stable
name: nginx
ports:
– containerPort: 80
volumeMounts:
– mountPath: “/var/log/nginx”
name: nginx-logs
readOnly: false

—
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx
name: nginx-svc
namespace: nginx-example
spec:
ports:
– port: 80
targetPort: 80
selector:
app: nginx
type: LoadBalancer

در اين فايل فضاهايي براي موارد زير مشاهده مي كنيم:
⦁ يك نام فضاي Nginx به نام nginx-example
⦁ استقرار Nginx متشكل از يك نمونه كپي شده از تصوير كانتينر nginx:stable
⦁ ادعاي واليوم مداوم 5Gi (به نام log-nginx) با استفاده از do-block-storage در StorageClass
⦁ يك سرويس LoadBalancer كه پورت 80 را در معرض ديد قرار مي دهد
با استفاده از kubectl apply موارد را ايجاد كنيد:
$kubectl apply -f examples/nginx-example.yaml
بايد خروجي زير را مشاهده كنيد:
Output
namespace/nginx-example created
persistentvolumeclaim/nginx-logs created
deployment.apps/nginx-deploy created
service/nginx-svc created

بررسي كنيد كه استقرار موفق باشد:
$kubectl get deployments –namespace=nginx-example
بايد براي سرويس my-nginx هم CLUSTER-IP داخلي و هم EXTERNAL-IP را مشاهده كنيد:
Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.245.147.61 159.203.48.191 80:30232/TCP 3m1s

به EXTERNAL-IP توجه داشته باشيد و آن را به سمت استفاده از مرورگرتان هدايت كنيد.
هنگامي كه در دسترس قرار گرفت به 1 رسيد ، IP خارجي تعادل بار Nginx را با استفاده از kubectl دريافت كنيد:

شما بايد صفحه خوشامدگويي NGINX زير را ببينيد:

اين نشان مي دهد كه Nginx Deployme شما و خدمات به روز و در حال اجرا هستند.
قبل از شبيه سازي سناريوي فاجعه ما ، ابتدا ورود به دسترسي Nginx (كه در يك حجم مداوم متصل به Nginx Pod ذخيره شده) را بررسي كنيد:
$kubectl get pods –namespace nginx-example
Output
NAME READY STATUS RESTARTS AGE
nginx-deploy-694c85cdc8-vknsk 1/1 Running 0 4m14s

اكنون ، داخل كانتينر در حال اجرا Nginx وارد شويد تا به يك پوسته در داخل آن برسيد:
$kubectl exec -it nginx-deploy-694c85cdc8-vknsk –namespace nginx-example — /bin/bash

به محض ورود به كانتينر Nginx برويد ، ورودهاي دسترسي Nginx را cat كنيد:

# cat /var/log/nginx/access.log
بايد برخي از ورودي هاي Nginx را مشاهده كنيد:
Output
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET / HTTP/1.1” 200 612 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET /favicon.ico HTTP/1.1” 404 153 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”

اين موارد را يادداشت كنيد (به ويژه زمانها) ، زيرا ما از آنها براي تأييد موفقيت در روش بازيابي استفاده خواهيم كرد. از pod خارج شويد:
$ exit
اكنون مي توانيم از روش پشتيبان گيري براي كپي كردن همه موارد nginx Kubernetes در Spaces استفاده كنيم و يك اسنپ شات از واليوم مداوم كه هنگام استقرار Nginx ايجاد كرديم را بگيريد.
$ velero backup create nginx-backup –selector app=nginx
برنامه –selector = nginx به سرور مجازي Velero دستور مي دهد تا فقط از موضوعات Kubernetes با انتخابگر ليبل app=nginx پشتيبان تهيه كند.
بايد خروجي زير را مشاهده كنيد:
Output
Backup request “nginx-backup” submitted successfully.
Run `velero backup describe nginx-backup` or `velero backup logs nginx-backup` for more details.

اجراي velero backup describe nginx-backup –details بايد خروجي زير را بعد از يك تأخير كوتاه ارائه دهد:
Output
Name: nginx-backup
Namespace: velero
Labels: velero.io/backup=nginx-backup
velero.io/pv=pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca
velero.io/storage-location=default
Annotations:

Phase: Completed

Namespaces:
Included: *
Excluded:

Resources:
Included: *
Excluded:
Cluster-scoped: auto

Label selector: app=nginx

Storage Location: default

Snapshot PVs: auto

TTL: 720h0m0s

Hooks:

Backup Format Version: 1

Started: 2020-01-02 23:45:30 -0500 EST
Completed: 2020-01-02 23:45:34 -0500 EST

Expiration: 2020-02-01 23:45:30 -0500 EST

Resource List:
apps/v1/Deployment:
– nginx-example/nginx-deploy
apps/v1/ReplicaSet:
– nginx-example/nginx-deploy-694c85cdc8
v1/Endpoints:
– nginx-example/nginx-svc
v1/Namespace:
– nginx-example
v1/PersistentVolume:
– pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca
v1/PersistentVolumeClaim:
– nginx-example/nginx-logs
v1/Pod:
– nginx-example/nginx-deploy-694c85cdc8-vknsk
v1/Service:
– nginx-example/nginx-svc

Persistent Volumes:
pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca:
Snapshot ID: dfe866cc-2de3-11ea-9ec0-0a58ac14e075
Type: ext4
Availability Zone:
IOPS:

اين خروجي نشان مي دهد كه پشتيبان گيري nginx-backup با موفقيت انجام شد. ليست منابع هر يك از موضوعات Kubernetes را كه در نسخه پشتيبان تهيه شده است نشان مي دهد. بخش آخر نشان مي دهد كه از PersistentVolume نيز با استفاده از اسنپ شات فايل سيستم نسخه پشتيبان تهيه شده است.
براي تأييد از داخل كنترل پنل vpsgol Cloud ، به فضاي حاوي فايل هاي پشتيبان Kubernetes خود برويد.
شما بايد يك دايركتوري جديد با نام nginx-backup را ببينيد كه حاوي فايل هاي پشتيبان Velero است.
با استفاده از نوار ناوبري در سمت چپ ، به قسمت تصاوير و سپس اسنپ شات ها برويد. در اسنپ شات ها ، به Volume برويد. شما بايد Snapshot مربوط به PVC ذكر شده در خروجي فوق را مشاهده كنيد.
اكنون مي توانيم فرآيند بازيابي را آزمايش كنيم.
بياييد ابتدا نام فضاي nginx-example را حذف كنيم. با اين كار همه چيز در نام فضا، از جمله Load Balancer و واليوم مداوم حذف مي شود:
$kubectl delete namespace nginx-example
تأييد كنيد كه ديگر نمي توانيد به Nginx در انتهاي Load Balancer دسترسي پيدا كنيد ، و اين كه به كارگيري برنامه nginx-example ديگر در حال اجرا نيست:
$kubectl get deployments –namespace=nginx-example
Output
No resources found in nginx-example namespace.

اكنون مي توانيم دوباره با استفاده از مشتري velero ، فرآيند بازيابي را انجام دهيم:
$ velero restore create –from-backup nginx-backup
در اينجا ما از create  براي ايجاد مورد Velero Restore از موضوع nginx-backup استفاده مي كنيم.
بايد خروجي زير را مشاهده كنيد:
Output
$Restore request “nginx-backup-20200102235032” submitted successfully.
$Run `velero restore describe nginx-backup-20200102235032` or `velero restore logs nginx-backup-20200102235032` for more details.
وضعيت اجراي بازيابي شده را بررسي كنيد:
$kubectl get deployments –namespace=nginx-example
Output
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deploy 1/1 1 1 58s
ايجاد واليوم مداوم را بررسي كنيد
$kubectl get pvc –namespace=nginx-example
Output
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nginx-logs Bound pvc-6b7f63d7-752b-4537-9bb0-003bed9129ca 5Gi RWO do-block-storage 75s

بازيابي همچنين LoadBalancer ايجاد كرد. گاهي اوقات سرويس با يك آدرس IP جديد ايجاد مي شود. بايد مجدداً آدرس EXTERNAL-IP را پيدا كنيد:

$kubectl get services –namespace nginx-example
Output
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-svc LoadBalancer 10.245.15.83 159.203.48.191 80:31217/TCP 97s
براي تأييد به روز رساني و اجراي Nginx ، يك بار ديگر به IP خارجي سرويس Nginx برويد.
در آخر ، ورودهاي مربوط به واليوم پايدار را بازبيني كنيد تا تأييد كنيد كه سابقه ورود پس از بازيابي ، حفظ شده است.
براي اين كار ، يك بار ديگر نام Pod را با استفاده از kubectl get دريافت كنيد:
$kubectl get pods –namespace nginx-example
Output
NAME READY STATUS RESTARTS AGE
nginx-deploy-694c85cdc8-vknsk 1/1 Running 0 2m20s

سپس به آن exec كنيد:
$kubectl exec -it nginx-deploy-694c85cdc8-vknsk –namespace nginx-example — /bin/bash
به محض ورود به كانتينر Nginx، ورودهاي دسترسي به Nginx را cat كنيد:
$cat /var/log/nginx/access.log
Output
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET / HTTP/1.1” 200 612 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”
10.244.0.119 – – [03/Jan/2020:04:43:04 +0000] “GET /favicon.ico HTTP/1.1” 404 153 “-” “Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0” “-”

شما بايد همان اقدامات دسترسي قبل از تهيه نسخه پشتيبان را ببينيد (بازه هاي زماني را يادداشت كنيد) كه تأييد ميكند كه بازيابي واليوم پايدار موفقيت آميز بوده است. توجه داشته باشيد پس از انجام بازيابي ، اگر از صفحه فرود Nginx بازديد كنيد ، ممكن است تلاش هاي بيشتري نياز باشد.
در اين مرحله ، ما با موفقيت از موضوعات Kubernetes خود در فضاهاي vpsgol و واليومهاي پايدار خود با استفاده از اسنپ شات هاي بلوك ذخيره سازي پشتيبان تهيه كرده ايم. ما يك سناريوي فاجعه را شبيه سازي كرديم و سرويس را به برنامه تست Nginx بازيابي كرديم.
نتيجه
در اين راهنما ابزار پشتيبان گيري Velero Kubernetes را روي يك خوشه مبتني بر vpsgol Kubernetes نصب و پيكربندي كرديم. ما اين ابزار را براي تهيه نسخه پشتيبان از موضوعات Kubernetes در vpsgol Spaces و پشتيبان گيري از واليوم هاي مداوم با استفاده از اسنپ شات هاي واليوم ذخيره سازي بلوك پيكربندي كرده ايم.

از Velero همچنين مي توان براي برنامه ريزي پشتيبان گيري منظم از خوشه Kubernetes براي بازيابي در برابر مشكلات استفاده كرد. براي اين كار مي توانيد از دستور velero schedule استفاده كنيد. Velero همچنين مي تواند براي انتقال منابع از يك خوشه به گروه ديگر استفاده شود.
براي كسب اطلاعات بيشتر در مورد vpsgol Spaces ، از مطالب رسمي Spaces كمك بگيريد. براي كسب اطلاعات بيشتر در مورد واليوم هاي ذخيره سازي بلوك ، با مستندات واليوم ذخيره سازي بلوك مشورت كنيد.
اين آموزش بر اساس README موجود در repo GitHub-plugin-plugin-digital-stackPointCloud

مقدمه
سيستم هاي مديريت ديتابيس هاي منطقي يك مؤلفه اصلي بسياري از وب سايت ها و برنامه ها است. آنها روشي ساختاري براي ذخيره ، سازماندهي و دسترسي به اطلاعات را ارائه مي دهند.
PostgreSQL يا Postgres يك سيستم مديريت ديتابيس منطقي است كه اجراي زبان جستجوي SQL را فراهم مي كند. و يك انتخاب متداول براي بسياري از پروژه هاي كوچك و بزرگ است و اين مزيت را دارد كه مطابق با استانداردها مي باشد و داراي بسياري از ويژگي هاي پيشرفته مانند تعاملات مطمئن و همزماني بدون قفل خواندن است.
در اين راهنما؛ Postgres را بر روي سرور مجازي CentOS 7 نصب خواهيد كرد و برخي از روش هاي اصلي براي استفاده از آن را فرا مي گيريد.
پيش نيازها
براي دنبال كردن اين آموزش ، به موارد زير نياز داريد:
يك سرور مجازي CentOS 7 كه با پيروي از راهنماي راه اندازي سرور مجازي اوليه ما با CentOS 7 و مراحل توصيه شده بعدي براي سرورهاي جديد CentOS 7 ما ، شامل كاربر غير ريشه با امتيازات sudo و فايروال تنظيم شده با firewalld پيكربندي شده باشد.
براي راه اندازي firewalld ، بخش پيكربندي يك فايروال اساسي در آموزش ستاپ توصيه شده براي سرورهاي جديد CentOS 7 را دنبال كنيد.
اگر ديتابيس ها بسيار فعال باشند و داراي نشان زماني در سوابق داخلي باشند ، مي توانند به ويژه در برابر تغييرات زمان سيستم آسيب پذير باشند. براي جلوگيري از برخي رفتارهاي متناقض كه در اثر ساعتهاي خارج از همگام سازي ناشي مي شود ، حتماً با دنبال كردن بخش همگام سازي پروتكل زماني شبكه و محدوده هاي زماني پيكربندي در آموزش مراحل اضافي براي سرور مجازيCentOS 7 جديد، همگام سازي پروتكل زماني شبكه را (NTP) تنظيم كنيد. .
مرحله 1 – نصب PostgreSQL
Postgres را مي توان با استفاده از منابع پيش فرض CentOS نصب كرد. اما در مورد نوشتن اين آموزش ، نسخه اي كه در منبع پايه CentOS 7 موجود است منسوخ شده است. بنابراين ، در اين آموزش از منبع رسمي Postgres استفاده خواهد شد.

قبل از اقدام به ايجاد منبع جديد ، جستجوي بسته هاي postgresql را از منبع CentOS-Base حذف كنيد. در غير اين صورت ، وابستگي ها ممكن است نسبت به postgresql تهيه شده توسط منبع پايه برطرف شود.
فايل پيكربندي منبع را با استفاده از ويرايشگر متن مورد نظر خود باز كنيد. در اين آموزش از vim استفاده مي شود:
$sudo vi /etc/yum.repos.d/CentOS-Base.repo
بخش هاي [base] و [update] را پيدا كنيد ، با فشار دادن i وارد حالت insert شويد و خط exclud = postgresql * را در هر دو بخش وارد كنيد. در نتيجه ، فايل شما به شرح زير خواهد بود ، با خطوط جديد برجسته شده است:
/etc/yum.repos.d/CentOS-Base.repo
…
[base]
name=CentOS-$releasever – Base
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7

exclude=postgresql*

#released updates
[updates]
name=CentOS-$releasever – Updates
mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates&infra=$infra
#baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
exclude=postgresql*
…

پس از اتمام ، ESC را فشار دهيد تا از حالت درج خارج شويد، سپس: wq و ENTER را براي ذخيره و خروج از فايل بزنيد. براي كسب اطلاعات بيشتر در مورد ويرايشگر متن vi و جانشين آن vim ، نصب و استفاده از ويرايشگر متن Vim را در آموزش Cloud Server ببينيد.
اكنون با استفاده از منبع رسمي PostgreSQL براي CentOS ، يك بسته تنظيمات منبع را نصب كنيد:

$sudo yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm
هنگامي كه اعلان به شما داده شد ، نصب را با y تأييد كنيد.
منبع PostgreSQL شامل اطلاعات مربوط به همه نسخه هاي موجود PostgreSQL است. با استفاده از دستور زير مي توانيد تمام بسته ها و نسخه هاي موجود را مشاهده كنيد:
$yum list postgresql*
نسخه مورد نظر PostgreSQL را انتخاب و نصب كنيد. در اين راهنما از نسخه PostgreSQL 11 استفاده خواهيد كرد.
براي نصب سرور مجازي PostgreSQL از دستور زير استفاده كنيد:
$sudo yum install postgresql11-server
در طي مراحل نصب از شما خواسته مي شود تا كليد GPG را با اعلاني مانند موارد زير وارد كنيد:
…
Importing GPG key 0x442DF0F8:
Userid : “PostgreSQL RPM Building Project ”
Fingerprint: 68c9 e2b9 1a37 d136 fe74 d176 1f16 d2e1 442d f0f8
Package : pgdg-redhat-repo-42.0-5.noarch (installed)
From : /etc/pki/rpm-gpg/RPM-GPG-KEY-PGDG
Is this ok [y/N]:

آن را با y تأييد كنيد تا نصب كامل شود.
اكنون كه نرم افزار نصب شده است ، شما براي تهيه خوشه ديتابيس جديد براي PostgreSQL مراحل ابتدايي را انجام خواهيد داد.
مرحله 2 – ايجاد يك خوشه ديتابيس جديد PostgreSQL
شما بايد قبل از استفاده از ديتابيس Postgres ، يك ديتابيس PostgreSQL  جديد ايجاد كنيد. يك خوشه ديتابيس مجموعه اي از بانكهاي داده است كه توسط يك سرور مجازي واحد مديريت مي شود. ايجاد يك خوشه ديتابيس شامل ايجاد دايركتوري هايي است كه در آن داده هاي ديتابيس قرار مي گيرد ، جداول كاتولوگ اشتراكي و بانكهاي اطلاعاتي template1 و postgres. را ايجاد ميكنند.
براي ايجاد يك ديتابيس جديد ، ديتابيس template1 لازم است. هر چيزي كه در آن ذخيره شده باشد ، هنگام ايجاد در يك ديتابيس جديد قرار مي گيرد. ديتابيس postgres يك ديتابيس پيش فرض است كه براي استفاده كاربران ، برنامه هاي كاربردي و برنامه هاي شخص ثالث طراحي شده است.

يك خوشه جديد براي ديتابيس PostgreSQL با initdb ايجاد كنيد:
$ sudo /usr/pgsql-11/bin/postgresql-11-setup initdb
خروجي زير را مشاهده خواهيد كرد:
Initializing database … OK

اكنون PostgreSQL را با استفاده از systemctl شروع و فعال كنيد:
$ sudo systemctl start postgresql-11
$ sudo systemctl enable postgresql-11
خروجي زير را مي دهد
Created symlink from /etc/systemd/system/multi-user.target.wants/postgresql-11.service to /usr/lib/systemd/system/postgresql-11.service.

اكنون كه PostgreSQL به روز شده و در حال اجرا است ، شما مي توانيد با استفاده از نقش ها ، ياد بگيريد كه چگونه Postgres كار مي كند و تفاوت آن با سيستم هاي مديريت ديتابيس مشابه شما كه ممكن است در گذشته استفاده كرده باشيد چيست.
مرحله 3 – استفاده از نقشها و بانكهاي اطلاعاتي PostgreSQL
به طور پيش فرض ، Postgres از مفهومي به نام نقش ها براي تأييد اعتبار و مجوز استفاده مي كند. اينها از بعضي جهات شبيه به حسابهاي معمولي يونيكس هستند اما Postgres بين كاربران و گروه ها فرق نمي گذارد و در عوض نقش انعطاف پذير تري را ترجيح مي دهد.
پس از نصب ، Postgres براي استفاده احراز هويت شناسايي تنظيم ميشود ، به اين معني كه نقش هاي Postgres با يك حساب كاربري سيستم Unix / Linux مرتبط مي شود. اگر نقشي در Postgres وجود داشته باشد ، يك نام كاربري يونيكس / لينوكس با همين نام قادر به ورود به عنوان آن نقش است.
روش نصب يك حساب كاربري به نام postgres ايجاد كرده است كه با نقش پيش فرض Postgres همراه است. براي استفاده از Postgres مي توانيد وارد آن حساب شويد.
چند روش براي استفاده از اين حساب براي دسترسي به Postgres وجود دارد.
انتقال به حساب Postgres
با تايپ كردن دستور زير به حساب Postgres در سرور مجازي خود سوييچ كنيد:
$ sudo -i -u postgres
اكنون مي توانيد با تايپ اين دستور فوراً به Postgres دسترسي پيدا كنيد:

$ psql
با اين كار شما وارد اعلان PostgreSQL مي شويد و از اينجا مي توانيد بلافاصله با سيستم مديريت ديتابيس ارتباط برقرار كنيد.
با تايپ كردن اين دستور از اعلان PostgreSQL خارج شويد:
Postgres=# q
اين شما را به خط فرمان سريع postgres Linux بازميگرداند. اكنون با دستور زير به حساب sudo اصلي خود برگرديد:
$ exit
دسترسي به يك Postgres سريع بدون تعويض حساب
همچنين مي توانيد دستور مورد نظر خود را با حساب postgres به طور مستقيم با sudo اجرا كنيد.
به عنوان مثال ، در نمونه آخر ، به شما دستور داده شد كه ابتدا با سوييچ كردن به كاربر Postgres و سپس اجراي psql براي باز كردن اعلان Postgres ، سريعاً بهPostgres برسيد. شما مي توانيد اين كار را در يك مرحله با اجراي فرمان واحد psql به عنوان كاربر postgres با sudo انجام دهيد ، مانند اين:
$ sudo -u postgres psql
با اين كار بدون پوسته bash مستقيماً وارد Postgres خواهيد شد.
دوباره مي توانيد با تايپ كردن اين دستور از بخش Postgres تعاملي خارج شويد:
Postgres=# q
در اين مرحله، از حساب Postgres براي رسيدن به اعلان psql استفاده كرديد. اما بسياري از موارد استفاده بيشتر به يك نقش Postgres نياز دارند. براي يادگيري نحوه پيكربندي نقشهاي جديد به خواندن متن ادامه دهيد.
مرحله 4 – ايجاد نقش جديد
در حال حاضر ، شما فقط نقش postgres ها را در ديتابيس پيكربندي كرده ايد. مي توانيد با استفاده از دستور Createrole نقش هاي جديدي را از خط فرمان ايجاد كنيد. فلگ –interactive نام نقش جديد را به شما اعلان ميكند و همچنين سؤال ميكند كه آيا مجوزهاي فوق كاربري بايد داته باشد يا خير.
اگر به عنوان حساب postgres وارد شويد ، مي توانيد با تايپ كردن اين دستور كاربر جديدي ايجاد كنيد:
postgres@server:$ createuser –interactive
در عوض ، اگر ترجيح مي دهيد بدون تغيير حساب عادي خود از sudo براي هر دستور استفاده كنيد ، تايپ كنيد:
$ sudo -u postgres createuser –interactive
اين متن با انتخاب هاي مختلفي شما را باخبر مي كند و بر اساس پاسخ هاي شما ، دستورات درست Postgres را براي ايجاد يك كاربر براي مشخصات شما اجرا مي كند. براي اين آموزش ، يك كاربر sammy ايجاد كنيد و به آن امتيازات فوق كاربر بدهيد:
Enter name of role to add: sammy
Shall the new role be a superuser? (y/n) y

با عبور برخي از فلگ هاي اضافي مي توانيد كنترل بيشتري به دست آوريد. گزينه ها را با مراجعه به صفحه man بررسي كنيد:
$ man createuser
نصب شما در Postgres اكنون كاربر جديدي دارد ، اما شما هنوز هيچ ديتابيسي اضافه نكرده ايد. در بخش بعدي اين روند توضيح داده شده است.
مرحله 5 – ايجاد يك ديتابيس جديد
فرض ديگري كه سيستم تأييد اعتبار Postgres بطور پيش فرض انجام مي دهد اين است كه براي هر نقشي كه براي ورود به سيستم استفاده مي شود ، آن نقش يك ديتابيس با همان نام دارد كه مي تواند به آن دسترسي داشته باشد.
اين بدان معني است كه ، اگر كاربري كه در آخرين بخش ايجاد كرده ايد ، sammy خوانده شود ، اين نقش سعي خواهد كرد به يك ديتابيس وصل شود كه به طور پيش فرض نيز sammy ناميده مي شود. مي توانيد با دستور createdb  ديتابيس مناسب ايجاد كنيد.
اگر به عنوان حساب postgres وارد ميشويد، مطمئناً شما مي توانيد چيزي شبيه اين تايپ خواهيد كرد:
postgres@server:$ createdb sammy
در عوض ، اگر ترجيح مي دهيد بدون تغيير از حساب عادي خود ، از sudo براي هر فرمان استفاده كنيد ، تايپ كنيد:
$ sudo -u postgres createdb sammy
اين انعطاف پذيري در صورت نياز چندين مسير براي ايجاد ديتابيس جديد فراهم مي كند.
اكنون كه يك ديتابيس جديد ايجاد كرده ايد ، با نقش جديد خود وارد آن خواهيد شد.

مرحله ششم – باز كردن اعلان Postgres با نقش جديد
براي ورود به تأييد هويت مبتني بر ident ، به يك كاربر لينوكس با همان نام و نقش ديتابيس Postgres خود نياز داريد.
اگر يك كاربر سازگار با لينوكس در دسترس نداريد ، مي توانيد يكي از آنها را با دستور adduser ايجاد كنيد. شما بايد اين كار را از حساب غير ريشه خود با امتيازات sudo انجام دهيد (به اين معني كه به عنوان كاربر postgres وارد نشده ايد):
$ sudo adduser sammy
پس از در دسترس بودن اين حساب جديد ، مي توانيد با تايپ كردن به ديتابيس سوييچ كنيد و وصل شويد:
$ sudo -i -u sammy
$ psql
يا مي توانيد اين كار را بصورت درون خطي انجام دهيد:
$ sudo -u sammy psql
اين دستور شما را به طور خودكار وارد مي كند.
اگر مي خواهيد كاربر شما به يك ديتابيس ديگر متصل شود ، مي توانيد با مشخص كردن ديتابيس مانند دستور زير اين كار را انجام دهيد:
$ psql -d postgres
پس از ورود به سيستم ، مي توانيد اطلاعات اتصال فعلي خود را با تايپ كردن دستور زير بررسي كنيد:
Sammy=# conninfo
خروجي زير را نشان خواهد داد:
You are connected to database “sammy” as user “sammy” via socket in “/var/run/postgresql” at port “5432”.

اين امر در صورت اتصال به ديتابيس هاي غير پيش فرض يا با كاربران غير پيش فرض مفيد است.
با اتصال به ديتابيس خود ، اكنون مي توانيد ايجاد و حذف جداول را امتحان كنيد.
مرحله 7 – ايجاد و حذف جداول
اكنون كه مي دانيد چگونه به سيستم ديتابيس PostgreSQL وصل شويد ، مي توانيد برخي از وظايف اساسي مديريت Postgres را ياد بگيريد.
ابتدا يك جدول براي ذخيره برخي داده ها ايجاد كنيد. به عنوان نمونه ، جدولي را تهيه خواهيد كرد كه برخي از تجهيزات زمين بازي را شرح مي دهد.
تركيب اصلي اين دستور به شرح زير است:
CREATE TABLE table_name (
column_name1 col_type (field_length) column_constraints,
column_name2 col_type (field_length),
column_name3 col_type (field_length)
);
اين دستورات به جدول اسمي مي دهند و سپس ستون ها و همچنين نوع ستون و حداكثر طول داده هاي ميدان را مشخص مي كنند. همچنين مي توانيد محدوديت هاي جدول را براي هر ستون به صورت اختياري اضافه كنيد.
مي توانيد اطلاعات بيشتري در مورد نحوه ايجاد ، حذف و مديريت جداول در PostgreSQL در يك آموزش Cloud Server دريافت كنيد.
براي اهداف توضيحي ، يك جدول ساده مانند اين ايجاد كنيد:
CREATE TABLE playground (
equip_id serial PRIMARY KEY,
type varchar (50) NOT NULL,
color varchar (25) NOT NULL,
location varchar(25) check (location in (‘north’, ‘south’, ‘west’, ‘east’, ‘northeast’, ‘southeast’, ‘southwest’, ‘northwest’)),
install_date date
);

اين دستورات يك جدول ايجاد مي كند كه تجهيزات زمين بازي را ذخيره مي كند. اين كار با يك شناسه تجهيزات شروع مي شود كه از نوع serial  است. اين نوع داده يك عدد صحيح است كه به طور خودكار رو به افزايش است. شما همچنين به اين ستون محدوديت primary keyرا داده ايد ، به اين معني كه مقادير بايد منحصر به فرد باشند و خنثي نباشند.
براي دو ستون (equip_id و install_date) ، دستورات طول فيلد را مشخص نمي كنند. دليل اين امر اين است كه برخي از انواع ستونها به طول مشخصي نياز ندارند زيرا طول دلالت بر نوع است.
دو دستور بعدي به ترتيب ستونهايي را براي نوع و رنگ تجهيزات ايجاد مي كنند كه هر يك از آنها نمي تواند خالي باشد. دستور بعد از اينها يك ستون مكان و يك محدوديت ايجاد مي كند كه نياز دارد اين مقدار يكي از هشت مقدار ممكن باشد. دستور آخر يك ستون تاريخ ايجاد مي كند كه تاريخ نصب تجهيزات را ثبت مي كند.
مي توانيد جدول جديد خود را با تايپ كردن دستور زير مشاهده كنيد:
Sammy=# d
خروجي زير را نشان مي دهد:
List of relations
Schema | Name | Type | Owner
——–+————————-+———-+——-
public | playground | table | sammy
public | playground_equip_id_seq | sequence | sammy
(2 rows)

جدول زمين بازي شما اينجاست ، اما چيزي به نام playground_equip_id_seq نيز وجود دارد كه از نوع sequence است. اين نمايشي از نوع serial  است كه شما به ستون equip_id خود داده ايد. اين شماره بعدي را در ترتيب دنبال مي كند و به طور خودكار براي ستون هاي اين نوع ايجاد مي شود.
اگر مي خواهيد فقط جدول بدون ترتيب را ببينيد ، مي توانيد تايپ كنيد:
Sammy=# dt
به خروجي زير منجر ميشود:
List of relations
Schema | Name | Type | Owner
——–+————+——-+——-
public | playground | table | sammy
(1 row)

در اين مرحله يك جدول نمونه ايجاد كرده ايد. در مرحله بعد ، سعي در اضافه كردن ، درخواست و حذف مطالب در آن جدول خواهيد كرد.
مرحله 8 – اضافه كردن ، جستجو و حذف داده ها در يك جدول
اكنون كه جدول داريد ، مي توانيد برخي از داده ها را در آن وارد كنيد.
به عنوان نمونه ، با فراخواني جدول موردنظر براي افزودن ، نامگذاري ستونها ، و سپس تهيه داده براي هر ستون ، يك slide و swing را اضافه كنيد:
Sammy=# INSERT INTO playground (type, color, location, install_date) VALUES (‘slide’, ‘blue’, ‘south’, ‘2017-04-28’);
Sammy=# INSERT INTO playground (type, color, location, install_date) VALUES (‘swing’, ‘yellow’, ‘northwest’, ‘2018-08-16’);
شما بايد هنگام وارد كردن داده ها مراقب باشيد تا از معدود مشكلات معمول جلوگيري شود. براي يك ، نام ستون ها را در علامت نق قول نگذاريد ، اما مقادير ستون كه وارد مي كنيد به نقل قول نياز دارند.
نكته ديگري كه بايد در نظر داشته باشيد اين است كه براي ستون equip_id مقداري وارد نمي كنيد. به اين دليل است كه هر زمان كه يك رديف جديد در جدول ايجاد شود ، به طور خودكار شكل ميگيرد.
با تايپ كردن دستور زير اطلاعاتي كه اضافه كرده ايد بازيابي كنيد:
Sammy=# SELECT * FROM playground;
خروجي زير را مشاهده خواهيد كرد:

equip_id | type | color | location | install_date
———-+——-+——–+———–+————–
1 | slide | blue | south | 2017-04-28
2 | swing | yellow | northwest | 2018-08-16
(2 rows)

در اينجا ، مي بينيد كه equip_id شما با موفقيت پر شده است و تمام داده هاي ديگر شما به درستي سازماندهي شده اند.
اگر slide روي زمين بازي خراب شد و مجبور شديد آن را حذف كنيد ، مي توانيد با تايپ كردن دستور زير سطر را از جدول خود حذف نماييد:
Sammy=# DELETE FROM playground WHERE type = ‘slide’;
جدول را دوباره فراخواني كنيد:
Sammy=# SELECT * FROM playground;
موارد زير را مشاهده خواهيد كرد:
equip_id | type | color | location | install_date
———-+——-+——–+———–+————–
2 | swing | yellow | northwest | 2018-08-16
(1 row)

توجه كنيد كه اسلايد شما ديگر جزئي از جدول نيست.
اكنون كه ورودي هاي خود را در جدول خود اضافه كرده ايد و حذف كرده ايد ، مي توانيد ستون ها را اضافه و حذف كنيد.

مرحله 9 – اضافه كردن و حذف ستون ها از يك جدول
پس از ايجاد جدول ، مي توانيد آن را تغيير دهيد تا ستون ها اضافه يا حذف شوند. براي نمايش آخرين بازديد نگهداري براي هر قطعه تجهيزات ، يك ستون اضافه كنيد:
Sammy=# ALTER TABLE playground ADD last_maint date;
اگر اطلاعات جدول خود را دوباره مشاهده كنيد ، مي بينيد كه ستون جديد اضافه شده است (اما هيچ داده اي وارد نشده است(:
Sammy=# SELECT * FROM playground;
خروجي زير را مشاهده خواهيد كرد:
equip_id | type | color | location | install_date | last_maint
———-+——-+——–+———–+————–+————
2 | swing | yellow | northwest | 2018-08-16 |
(1 row)

حذف ستون به همين سادگي است. اگر متوجه شديد كه خدمه كاري شما از يك ابزار جداگانه براي پيگيري تاريخچه نگهداري استفاده مي كنند ، مي توانيد ستون را با تايپ كردن اين دستور حذف كنيد:
Sammy=# ALTER TABLE playground DROP last_maint;
اين ستون last_maint و مقادير موجود در آن را حذف مي كند ، اما تمام داده هاي ديگر را دست نخورده مي گذارد.
با افزودن و حذف ستونها، مي توانيد داده هاي موجود را در مرحله آخر به روز كنيد.
مرحله 10 – به روزرساني داده ها در يك جدول
تاكنون ياد گرفته ايد كه چگونه مي توانيد سوابق را به يك جدول اضافه كنيد و چگونه آنها را حذف كنيد ، اما اين آموزش هنوز نحوه تغيير ورودي هاي موجود را پوشش نداده است.
مي توانيد مقادير ورودي موجود را با فراخواني ركورد مورد نظر خود به روز كنيد و ستون را روي مقدار مورد نظر خود تنظيم كنيد. مي توانيد از سوابق swing  (با هر swing در جدول شما منطبق ميشود) استفاده كنيد و رنگ آن را به رنگ قرمز تغيير دهيد:
Sammy=# UPDATE playground SET color = ‘red’ WHERE type = ‘swing’;
با فراخواني داده ها دوباره مي توانيد تأييد كنيد كه اين عمليات با موفقيت انجام شد:
Sammy=# SELECT * FROM playground;
خروجي زير را مشاهده خواهيد كرد:
equip_id | type | color | location | install_date
———-+——-+——-+———–+————–
2 | swing | red | northwest | 2010-08-16
(1 row)

همانطور كه مشاهده مي كنيد ، اكنون اسلايدها به عنوان قرمز ثبت شده است.
نتيجه
اكنون تنظيم PostgreSQL در سرور مجازي CentOS 7 خود را انجام داده ايد. با اين حال ، هنوز چيزهاي بيشتري براي يادگيري Postgres وجود دارد. در اينجا چند راهنماي ديگر كه نحوه استفاده از Postgres را پوشش مي دهند آورده شده است:
مقايسه سيستم هاي مديريت ديتابيس منطقي
با نحوه ايجاد و مديريت جداول با Postgres آشنا شويد
در مديريت نقش ها و مجوزها حرفه اي تر شويد
فراخواني مهارت در Postgres با Selec

مقدمه
با حركت ابزارهاي گسترش دهنده به سمت cloud ، پذيرش پلتفرم cloud IDE (محيط پيشرفت در هم تنيده) در حال رشد است. Cloud IDE از هر نوع دستگاه مدرن از طريق مرورگرهاي وب قابل دسترسي است و براي سناريوهاي همكاري در زمان واقعي مزاياي بسياري را ارائه مي دهند. كار در يك Cloud IDE ، يك محيط توسعه و آزمايش يكپارچه را براي شما و تيم شما ايجاد مي كند ، در عين حال ناسازگاري هاي پلتفرم را به حداقل مي رساند. چون از طريق مرورگرهاي وب قابل دسترسي است ، Cloud IDE ها از هر نوع دستگاه مدرن در دسترس هستند.
Eclipse Theia يك Cloud IDE قابل توسعه است كه بر روي يك سرور مجازي از راه دور و از يك مرورگر وب قابل دسترسي است. از لحاظ بصري ، طراحي شده است كه به طور مشابه با Microsoft Visual Studio Code ديده شود و با آن كار شود ، به اين معني كه از بسياري از زبان هاي برنامه نويسي پشتيباني مي كند ، داراي يك طرح انعطاف پذير و يك ترمينال يكپارچه است. آنچه Eclipse Theia را از ديگر نرم افزارهاي cloud IDE جدا مي كند قابليت توسعه آن است. مي توان آن را با استفاده از افزونه هاي سفارشي اصلاح كرد ، كه به شما امكان مي دهد يك Cloud IDE متناسب با نيازهاي خود تهيه كنيد.
در اين آموزش ،Eclipse Theia را با استفاده از Docker Compose ، يك ابزار اركستر، به سرور مجازي Ubuntu 18.04 خود منتقل خواهيد كرد. شما آن را در دامنه خود با استفاده از nginx-غير مجاز مي باشد ، يك سيستم خودكار براي Docker قرار مي دهيد كه فرايند پيكربندي Nginx را ساده تر مي كند تا به عنوان يك پروكسي معكوس براي يك container سرويس دهد. شما با استفاده از يك گواهي نامه Let Encrypt TLS رايگان ، كه با استفاده از افزونه تخصصي آن تهيه مي كنيد ، آن را ايمن خواهيد كرد. در پايان ، شما بايد Eclipse Theia را روي سرور مجازي Ubuntu 18.04 خود از طريق HTTPS در دسترس داشته باشيد و از كاربر بخواهيد وارد شود.
پيش نيازها
⦁ يك سرور مجازي Ubuntu 18.04 با امتيازات اصلي و يك حساب ثانويه و غير ريشه. مي توانيد با دنبال كردن راهنماي تنظيم اوليه سرور مجازي ما براي Ubuntu 18.04 ، اين تنظيمات را انجام دهيد. براي اين آموزش كاربر غير ريشه sammy است.
⦁ Docker نصب شده روي سرور مجازي شما. مرحله 1 و مرحله 2 نحوه نصب Docker را در اوبونتو 18.04 دنبال كنيد. براي آشنايي با Docker ، به اكوسيستم Docker: مقدمه اي بر مؤلفه هاي مشترك مراجعه كنيد.
⦁ Docker compose روي سرور مجازي شما نصب است. مرحله 1 نحوه نصب Docker Compose را در اوبونتو 18.04 دنبال كنيد.
⦁ نام دامنه كاملاً ثبت شده. در اين آموزش كلا از theia.your_domain استفاده مي شود. مي توانيد نام دامنه را در Namecheap خريداري كنيد ، يكي از آنها را به صورت رايگان در Freenom دريافت كنيد ، يا از ثبت دامنه مورد نظر خود استفاده كنيد.
⦁ يك ثبت A DNS با theia.your_domain كه به آدرس IP عمومي سرور مجازي شما اشاره ميكند. براي جزئيات بيشتر در مورد چگونگي اضافه كردن آنها مي توانيد اين معرفي را در vpsgol DNS دنبال كنيد.
مرحله 1 – استفاده از پروكسي nginx با Let’s Encrypt
در اين بخش nginx-غير مجاز مي باشد و افزونه Let’s Encrypt را با استفاده از Docker Compose به كار ميگيريد. اين امر امكان تهيه و نوسازي مجوز خودكار TLS را فراهم مي كند ، به طوري كه هنگام استقرار Eclipse Theia از طريق HTTPS در دامنه شما قابل دسترسي خواهد بود.
براي اهداف اين آموزش ، تمام فايل ها را تحت ~ / eclipse-theia ذخيره مي كنيد. با اجراي دستور زير دايركتوري ايجاد كنيد:
⦁ $ mkdir ~/eclipse-theia
به آن مراجعه كنيد:
⦁ $ cd ~/eclipse-theia
پيكربندي Docker Compose را براي nginx-غير مجاز مي باشد در فايلي به نام nginx-غير مجاز مي باشد-compose.yaml ذخيره خواهيد كرد. آن را با استفاده از ويرايشگر متن خود ايجاد كنيد:
⦁ $nano nginx-غير مجاز مي باشد-compose.yaml
خطوط زير را اضافه كنيد:
~/eclipse-theia/nginx-غير مجاز مي باشد-compose.yaml
version: ‘2’

services:
nginx-غير مجاز مي باشد:
restart: always
image: jwilder/nginx-غير مجاز مي باشد
ports:
– “80:80”
– “443:443”
volumes:
– “/etc/nginx/htpasswd:/etc/nginx/htpasswd”
– “/etc/nginx/vhost.d”
– “/usr/share/nginx/html”
– “/var/run/docker.sock:/tmp/docker.sock:ro”
– “/etc/nginx/certs”

letsencrypt-nginx-غير مجاز مي باشد-companion:
restart: always
image: jrcs/letsencrypt-nginx-غير مجاز مي باشد-companion
volumes:
– “/var/run/docker.sock:/var/run/docker.sock:ro”
volumes_from:
– “nginx-غير مجاز مي باشد”

در اينجا شما دو سرويس را تعريف مي كنيد كه Docker Compose اجرا خواهد كرد ، nginx-غير مجاز مي باشد و همراه آن Let’s Encrypt. براي پروكسي ، شما jwilder / nginx-غير مجاز مي باشد را به عنوان تصوير مشخص ميكنيد، پورت هاي HTTP و HTTPS را نقشه برداري مي كنيد ، و حجم هايي را تعريف مي كنيد كه در زمان اجرا در دسترس شما خواهد بود.
حجم ها دايركتوري هايي در سرور مجازي شما هستند كه سرويس تعريف شده به آنها دسترسي كامل خواهد داشت ، كه بعداً براي تنظيم تأييد اعتبار كاربر از آنها استفاده خواهيد كرد. براي دستيابي به اين هدف ، از جلد اول ليست استفاده مي كنيد ، كه دايركتوري محلي / etc / nginx / htpasswd را به همان قسمت موجود در داخل آن نگاشت مي كشد. در آن پوشه ، nginx-غير مجاز مي باشد انتظار دارد فايلي را به نام دامنه هدف پيدا كند ، كه حاوي اطلاعات ورود به سيستم براي احراز هويت كاربر در قالب htpasswd (نام كاربري: hashed_password) است.
براي افزودن ، شما تصوير Docker را نامگذاري مي كنيد و با تعيين يك حجم امكان دسترسي به سوكت Docker را مي دهيد. سپس ، شما مشخص مي كنيد كه اين افزونه بايد دسترسي به حجمهاي تعريف شده براي nginx-غير مجاز مي باشد را ادامه دهد. هر دو سرويس
تنظيمات راه اندازي مجدد دارند ، كه روي ALWAYS تنظيم ميشود و به Docker دستور مي دهد كانتينر را در صورت خرابي يا ريبوت سيستم مجدداً راه اندازي كند.
فايل را ذخيره كنيد و ببنديد.
پيكربندي را با اجراي دستور انجام دهيد:
⦁ $ docker-compose -f nginx-غير مجاز مي باشد-compose.yaml up -d
در اينجا نام فايل nginx-غير مجاز مي باشد-compose.yaml را در پارامتر -f دستور docker-compose مي گذاريد ، كه فايل را براي اجرا مشخص مي كند. سپس ، شما فعل UP را مي گذرانيد كه به آن دستور مي دهد كانتينرها را اجرا كند. پرچم -d حالت جداشده را فعال مي سازد ، به اين معني كه Docker Compose كانتينرها را در پس زمينه اجرا مي كند.
خروجي نهايي به شرح زير خواهد بود:
Output
Creating network “eclipse-theia_default” with the default driver
Pulling nginx-غير مجاز مي باشد (jwilder/nginx-غير مجاز مي باشد:)…
latest: Pulling from jwilder/nginx-غير مجاز مي باشد
8d691f585fa8: Pull complete
5b07f4e08ad0: Pull complete
…
Digest: sha256:dfc0666b9747a6fc851f5fb9b03e65e957b34c95d9635b4b5d1d6b01104bde28
Status: Downloaded newer image for jwilder/nginx-غير مجاز مي باشد:latest
Pulling letsencrypt-nginx-غير مجاز مي باشد-companion (jrcs/letsencrypt-nginx-غير مجاز مي باشد-companion:)…
latest: Pulling from jrcs/letsencrypt-nginx-غير مجاز مي باشد-companion
89d9c30c1d48: Pull complete
668840c175f8: Pull complete
…
Digest: sha256:a8d369d84079a923fdec8ce2f85827917a15022b0dae9be73e6a0db03be95b5a
Status: Downloaded newer image for jrcs/letsencrypt-nginx-غير مجاز مي باشد-companion:latest
Creating eclipse-theia_nginx-غير مجاز مي باشد_1 … done
Creating eclipse-theia_letsencrypt-nginx-غير مجاز مي باشد-companion_1 … done

شما nginx-غير مجاز مي باشد و همراهش Let’s Encrypt را با استفاده از Docker Compose به كار گرفته ايد. اكنون مي توانيد Eclipse Theia را در دامنه خود تنظيم كرده و آن را ايمن كنيد.
مرحله 2 – به كارگيري Eclipse Theia دوكر شده
در اين بخش ، فايلي را ايجاد خواهيد كرد كه شامل هر تركيب ورود به سيستم مجاز است كه كاربر بايد آن را وارد كند. سپس Eclipse Theia را با استفاده از Docker Compose به سرور مجازي خود منتقل مي كنيد و با استفاده از nginx-غير مجاز مي باشد آن را در دامنه امن خود قرار مي دهيد.
همانطور كه در مرحله قبل توضيح داده شد ، nginx-غير مجاز مي باشد انتظار دارد كه تركيب هاي ورود به سيستم در فايلي به نام دامنه در معرض ، با فرمت htpasswd قرار بگيرند و در دايركتوري / etc / nginx / htpasswd در كانتينر ذخيره شوند. همانطور كه در پيكربندي nginx-غير مجاز مي باشد مشخص كرده ايم ، دايركتوري محلي كه به دايركتوري مجازي نگاشت مي كند ، نيازي به يكسان بودن ندارد.
براي ايجاد تركيبات ورود ، ابتدا با اجراي دستور زير بايد htpasswd را نصب كنيد:
⦁ $ sudo apt install apache2-utils

پكيج apache2-utils حاوي برنامه htpasswd است.
دايركتوري / etc / nginx / htpasswd را ايجاد كنيد:
⦁ $ sudo mkdir -p /etc/nginx/htpasswd
فايلي ايجاد كنيد كه ورود به سيستم را براي دامنه شما ذخيره كند:

⦁ $ sudo touch /etc/nginx/htpasswd/theia.your_domain

به ياد داشته باشيد theia.your_domain را با دامنه Eclipse Theia خود جايگزين كنيد.
براي افزودن نام كاربري و رمز ورود ، دستور زير را اجرا كنيد:
⦁ $ sudo htpasswd /etc/nginx/htpasswd/theia.your_domain username
USERNAME را با نام كاربري كه مي خواهيد اضافه كنيد جايگزين كنيد. از شما دوبار رمز عبور خواسته مي شود. پس از ارائه آن ، htpasswd نام كاربري و جفت رمز عبور را در انتهاي فايل اضافه مي كند. مي توانيد اين دستور را به هر تعداد ورود به سيستم كه ميخواهيد تكرار كنيد.
اكنون ، پيكربندي را براي استقرار Eclipse Theia ايجاد خواهيد كرد. شما آن را در فايلي به نام eclipse-theia-compose.yaml ذخيره خواهيد كرد. آن را با استفاده از ويرايشگر متن خود ايجاد كنيد:
⦁ $ nano eclipse-theia-compose.yaml
خطوط زير را اضافه كنيد:
~/eclipse-theia/eclipse-theia-compose.yaml
version: ‘2.2’

services:
eclipse-theia:
restart: always
image: theiaide/theia:next
init: true
environment:
– VIRTUAL_HOST=theia.your_domain
– LETSENCRYPT_HOST=theia.your_domain

در اين پيكربندي ، شما يك سرويس واحد به نام eclipse-theia با ريستارت براي ALWAYS و theiaide/theia:next به عنوان تصوير كانتينر تعريف مي كنيد: شما همچنين مي توانيد init را روي true تنظيم كنيد تا به Docker دستور دهيد هنگام اجراي Eclipse Theia در داخل كانتينر ، از init به عنوان مدير اصلي فرآيند استفاده كند.
سپس دو متغير محيط را در بخش environment مشخص مي كنيد: VIRTUAL_HOST و LETSENCRYPT_HOST. اولين مورد به پروكسي nginx منتقل مي شود و به آن مي گويد كانتينر چه دامنه اي را بايد در معرض ديد قرار دهيد ، در حالي كه دومي توسط افزونه Let’s Encrypt آن استفاده مي شود و مشخص مي كند كه براي كدام دامنه درخواست گواهينامه TLS شود. مگر اينكه يك wildcard را به عنوان مقدار VIRTUAL_HOST تعيين كنيد ، اين دو مقدار بايد يكسان باشند.
به ياد داشته باشيد theia.your_domain را با دامنه مورد نظر خود جايگزين كنيد ، سپس فايل را ذخيره كنيد و ببنديد. اكنون با اجراي دستور زير Eclipse Theia را اجرا كنيد:
⦁ $ docker-compose -f eclipse-theia-compose.yaml up -d
خروجي نهايي مشابه زير به نظر مي رسد:
Output
…
Pulling eclipse-theia (theiaide/theia:next)…
next: Pulling from theiaide/theia
63bc94deeb28: Pull complete
100db3e2539d: Pull complete
…
Digest: sha256:c36dff04e250f1ac52d13f6d6e15ab3e9b8cad9ad68aba0208312e0788ecb109
Status: Downloaded newer image for theiaide/theia:next
Creating eclipse-theia_eclipse-theia_1 … done

سپس در مرورگر خود به دامنه مورد استفاده براي Eclipse Theia برويد. مرورگر شما فوريتي را به شما نشان مي دهد كه از شما خواسته مي شود وارد شويد. پس از ارائه اطلاعات صحيح ، شما وارد Eclipse Theia مي شويد و بلافاصله رابط كاربري گرافيكي آن را مشاهده مي كنيد. در نوار آدرس
يك پدلاك را مشاهده خواهيد كرد كه نشان مي دهد اتصال امن است. اگر اين را بلافاصله مشاهده نكرديد ، چند دقيقه صبر كنيد تا گواهينامه هاي TLS ارائه شود ، سپس صفحه را مجدد بارگيري كنيد.

اكنون كه مي توانيد به راحتي به cloud IDE خود دسترسي داشته باشيد ، در مرحله بعد شروع به استفاده از ويرايشگر خواهيد كرد.

مرحله 3 – استفاده از رابط Eclipse Theia
در اين بخش به بررسي برخي از ويژگي هاي رابط Eclipse Theia مي پردازيد.
در سمت چپ IDE ، يك رديف عمودي از چهار دكمه وجود دارد كه متداول ترين ويژگي هاي مورد استفاده را در يك صفحه جانبي باز مي كند.
اين نوار قابل تنظيم است بنابراين مي توانيد اين نماها اين نوار قابل سفارشي

مقدمه
SSH راه اصلي براي اتصال به سرورهاي راه دور لينوكس و يونيكس مانند از طريق خط فرمان است. كه يك اتصال مطمئن فراهم مي كند كه مي توانيد از آن براي اجراي دستورات ، تعامل با سيستم و حتي تونل زدن از ميان ترافيك نامربوط استفاده كنيد.
بيشتر كاربران از اصول اوليه چگونگي شروع و اتصال به يك سرور از راه دور با يك فرمان مانند زير آگاه هستند:
ssh username@remote_server

با اين حال ، گزينه هاي بيشتري در رابطه با پيكربندي Demon SSH وجود دارد كه مي تواند براي افزايش امنيت ، مديريت اتصالات كاربر و غيره مفيد باشد. ما در مورد برخي از گزينه هاي موجود در اختيار شما بحث خواهيم كرد تا كنترل دقيق تري روي دسترسي SSH داشته باشيد. .
ما اين مفاهيم را به طور نمونه از Ubuntu 12.04 VPS استفاده خواهيم كرد ، اما هر توزيع مدرن لينوكس بايد به روشي مشابه عمل كند.
كاوش در فايل پيكربندي SSHD
منبع اصلي پيكربندي مربوط به Demon SSH در فايل / etc / ssh / sshd_config است. توجه داشته باشيد كه اين با فايل ssh_config متفاوت است ، كه پيش فرض سمت مشتري را مشخص مي كند.
اكنون فايل را با امتيازات ادمين باز كنيد:
sudo nano /etc/ssh/sshd_config

شما يك فايل با ويژگي هاي كاملاً متفاوت را مشاهده خواهيد كرد و خوشبختانه (بسته به توزيع خود) نظرهاي زيادي را نيز مشاهده ميكنيد. در حالي كه اكثر توزيع ها كار نسبتاً خوبي براي ايجاد پيش فرض هاي عاقلانه انجام مي دهند ، همچنان جاي بهبود و سفارشي سازي وجود دارد.
بياييد به برخي از گزينه هايي كه قبلاً در فايل ما در اوبونتو 12.04 تنظيم شده اند بپردازيم:
پورت ها و پروتكل ها
پورت 22: پورتي را كه Daemon SSH به دنبال اتصال در آن است ، مشخص مي كند. به طور پيش فرض ، اكثر مشتري ها و سرورها در درگاه 22 كار مي كنند ، اما تغيير دادن آن به درگاه متفاوت مي تواند به طور بالقوه ميزان تلاش ورود به سيستم توسط SSH توسط كاربران مخرب را كاهش دهد.
پروتكل 2: SSH از طريق دو نسخه پروتكل بوده است. مگر اينكه به طور خاص نياز به پشتيباني مشترياني داشته باشيد كه فقط مي توانند در پروتكل 1 كار كنند ، توصيه مي شود اين موارد را رها كنيد.
كليدها و جدايي
HostKey / etc / ssh / ssh_host…: اين خطوط كليدهاي هاست را براي سرور مشخص مي كنند. از اين كليدها براي شناسايي سرور براي اتصال مشتري استفاده مي شود. اگر مشتري قبلاً با سرور ارتباط برقرار كرده باشد ، مي تواند از اين كليد براي اعتبار سنجي اتصال جديد استفاده كند.
UsePrivilegeSeparation yes: اين گزينه به SSH اجازه مي دهد تا فرآيندهاي كودك را افزايش دهد كه فقط امتيازات لازم را براي انجام وظايف خود دارند. اين يك ويژگي ايمني براي جداسازي فرايندها در صورت بهره برداري امنيتي است.
KeyRegenerationInterval and ServerKeyBits: اين گزينه ها روي كليد سرور توليد شده براي پروتكل SSH 1 تأثير مي گذارند. اگر خواستار اتصال كانكشن هاي خود به پروتكل 2 هستيد ، لازم نيست كه نگران اين موضوع باشيد.

ورود به سيستم و محدوديت ها
SyslogFacility and LogLevel : اين گزينه ها نحوه ورود به سيستم را مشخص مي كنند. گزينه اول مربوط به كد تسهيلات براي پيام هاي logging است و گزينه دوم سطح ورود به سيستم يا ميزان جزئيات را مي گويد.
LoginGraceTime 120: تعداد ثانيه هايي است كه سرور قبل از جدا شدن از مشتري در صورت عدم ورود موفق به سيستم ، منتظر مي ماند.
PermitRootLogin yes: اين گزينه امكان SSH را با استفاده از حساب root امكان پذير يا رد مي كند. از آنجا كه حساب روت يكي از مواردي است كه حمله كننده مي داند در دستگاه سرور وجود دارد و از آنجا كه دسترسي نامحدود به دستگاه را فراهم مي كند ، اغلب يك حساب كاربري بسيار هدفمند است. وقتي يك حساب كاربري معمولي را با امتيازات sudo پيكربندي كرديد تنظيم اين گزينه روي حالت “خير” توصيه مي شود.
StrictModes yes: اين به SSH مي گويد كه از پرونده هاي پيكربندي سطح كاربر كه مجوزهاي صحيحي ندارند، چشم پوشي كند. اگر كاربر پرونده هاي پيكربندي خود را به صورت جهاني قابل خواندن قرار دهد ، پيامدهاي امنيتي خواهد داشت. تا زماني كه اين مشكل برطرف شود، بهتر است دسترسي برداشته باشد.
IgnoreRhosts and RhostsRSAAuthentication : اين گزينه ها مشخص مي كند كه آيا احراز هويت به سبك rhost پذيرفته خواهد شد يا خير. اين دستور پروتكل 1 است كه در مورد پروتكل 2 صدق نمي كند.
HostbasedAuthentication no: اين نسخه پروتكل 2 از مورد فوق است. در اصل، اجازه مي دهد تا احراز هويت بر اساس ميزبان مشتري در حال اتصال انجام شود. معمولاً فقط براي محيط هاي ايزوله قابل قبول است ، زيرا امكان جعل اطلاعات منبع وجود دارد. شما مي توانيد اطلاعات ميزبان را در يك فايل /etc/ssh/shosts.equiv يا فايل /etc/hosts.equiv مشخص كنيد. اين خارج از محدوده اين راهنما ميباشد.
PermitEmptyPasswords no: اين گزينه دسترسي SSH را براي حساب هايي كه رمز عبور ندارند در هنگام تأييد رمز عبور محدود مي كند. اين مي تواند يك خطر امنيتي بزرگ باشد و تقريباً هرگز نبايد آن را تغيير دهيد.
ChallengeResponseAuthentication: اين خط يك نوع تأييد پاسخ-چالش را فعال يا غيرفعال مي كند كه مي توان از طريق PAM پيكربندي كرد. اين بحث خارج از محدوده اين راهنما است.

نمايش
X11Forwarding yes: اين گزينه به شما امكان مي دهد تا واسط هاي گرافيكي X11كاربر را براي برنامه هاي روي سرور به دستگاه مشتري منتقل كنيد. اين بدان معني است كه مي توانيد يك برنامه گرافيكي را روي يك سرور شروع كنيد، و با آن در سيستم مشتري تعامل داشته باشيد. مشتري بايد يك سيستم X در دسترس داشته باشد. مي توانيد اين موارد را در OS X نصب كنيد و هر لينوكس دسكتاپي اين قابليت را دارد.
X11DisplayOffset 10: اين يك آفست براي شماره نمايشگر sshd براي ارسال X11 است. اين افست اجازه مي دهد تا SSH باعث ايجاد پنجره هاي X11 شود تا از درگيري با سرور X موجود جلوگيري كند.
PrintMotd no: اين گزينه مشخص مي كند كه Daemon SSH نبايد پيام فايل روز را بخواند و نمايش دهد. اين گاهي اوقات توسط خود shell خوانده مي شود ، بنابراين ممكن است شما نياز به تغيير پرونده هاي ترجيحي shell خود نيز داشته باشيد.
PrintLastLog yes: اين به Daemon SSH مي گويد تا اطلاعات آخرين باري كه وارد سيستم شديد را چاپ كند.

اتصال و محيط
TCPKeepAlive yes: مشخص مي كند كه آيا پيام هاي نگهدارنده TCP به دستگاه مشتري ارسال مي شوند. اين مي تواند به سرور در هنگام بروز مشكل و قطع اتصال كمك كند. اگر اين گزينه غيرفعال باشد ، در صورت بروز مشكل در شبكه ، اتصالات از بين نمي روند ، كه مي تواند خوب باشد ، اما همچنين بدان معني است كه ارتباط كاربران مي تواند از هم قطع شود و همچنان به قفل كردن منابع ادامه دهند.
AcceptEnv LANG LC_ *: اين گزينه به شما امكان مي دهد متغيرهاي محيطي خاصي را از دستگاه مشتري قبول كنيد. در اين مثال خاص ، ما متغيرهاي زبان را مي پذيريم ، كه مي تواند به بخش shell كمك كند كه به درستي براي مشتري نمايش داده شود.
Subsystem sftp /usr/lib/openssh/sftp-serve: زير سيستم هاي خارجي را كه مي توان با SSH استفاده كرد پيكربندي مي كند. در اين مثال سرور SFTP و مسير اجراي آن مشخص شده است.
UsePAM yes: اين مشخص مي كند كه PAM (ماژول هاي تأييد قابل اتصال) براي كمك به تأييد اعتبار كاربران در دسترس خواهد بود.
اين امر به گزينه هاي پيش فرض فعال شده دستگاه Ubuntu 12.04 ما احتياج دارد. در مرحله بعدي، بگذاريد درباره برخي گزينه هاي ديگر صحبت كنيم كه ممكن است براي تنظيم يا تغيير براي شما مفيد باشد.
ساير گزينه هاي SSHD
چندين گزينه ديگر وجود دارد كه مي توانيم براي Daemon SSH خود تعيين كنيم. برخي از اين موارد ممكن است فوراً براي شما مفيد باشد ، در حالي كه برخي ديگر فقط در شرايط خاص مي توانند مفيد باشند. ما در اينجا به همه موارد نمي پردازيم ، اما برخي از موارد مفيد را مرور خواهيم كرد.
فيلتر كاربري و گروهي
برخي گزينه ها به شما امكان مي دهند دقيقاً كنترل كنيد كه كاربران از چه طريق امكان ورود به سيستم از طريق SSH را دارند. اين گزينه ها بايد به صورت انحصاري در نظر گرفته شوند. به عنوان مثال ، گزينه AllowUsers به ​​اين معني است كه از دسترسي ساير كاربران جلوگيري مي شود.
AllowGroups: اين گزينه به شما امكان مي دهد نام گروه ها را روي سرور مشخص كنيد. فقط كاربراني كه عضو يكي از اين گروه ها هستند ، مي توانند وارد سيستم شوند. اين يك ليست سفيد از گروه هايي ايجاد مي كند كه بايد دسترسي داشته باشند.
AllowUsers: مشابه گزينه فوق است ، اما كاربران خاصي را كه مجاز به ورود به سيستم هستند مشخص مي كند. هر كاربر كه در اين ليست نباشد قادر به ورود به سيستم نخواهد بود. و به عنوان يك ليست سفيد كاربري كار مي كند.
DenyGroups: اين گزينه يك ليست سياه از گروههايي را ايجاد مي كند كه نبايد اجازه ورود به سيستم را داشته باشند. كاربراني كه به اين گروه ها تعلق دارند ، اجازه دسترسي ندارند.
DenyUsers: اين يك ليست سياه براي كاربران است. به طور خاص مشخص مي كند كه به كدام يك از كاربران امكان ورود به سيستم از طريق SSH داده نمي شود.
علاوه بر اين ، برخي از گزينه هاي محدود كننده ديگر نيز در دسترس هستند. اينها را مي توان در رابطه با هر يك از گزينه هاي فوق استفاده كرد:
Match: اين گزينه امكان كنترل بسيار دقيق تر بر روي افرادي را دارد كه تحت چه شرايطي مي توانند تأييد كنند. اين مجموعه گزينه هاي متفاوتي را مشخص مي كند كه هنگام اتصال يك كاربر يا گروه خاص بايد از آنها استفاده شود. ما بعداً با جزئيات بيشتري در مورد اين موضوع بحث خواهيم كرد.
RevokenKeys: اين به شما امكان مي دهد ليستي از كليدهاي عمومي ابطال شده را مشخص كنيد. اين كار از ورود كليدهاي ذكر شده براي ورود به سيستم جلوگيري مي كند.
گزينه هاي متفرقه
گزينه هايي وجود دارد كه مي توانيم از آنها استفاده كنيم تا پيكربندي كنيم چه ترافيك شبكه اي را Daemon SSH به آن توجه خواهد كرد:
AddressFamily: اين گزينه مشخص مي كند كه چه نوع آدرس هايي را انتخاب مي كنيد كه اتصالات آن ها را بپذيريد. به طور پيش فرض ، مقدار “هر” است ، اما مي توانيد “inet” را براي آدرسهاي IPv4 يا “inet6” را براي آدرسهاي IPv6 قرار دهيد.
ListenAddress: اين گزينه به شما امكان مي دهد تا به Daemon SSH بگوييد كه در يك آدرس و پورت خاص گوش كند. Daemon به طور پيش فرض تمام آدرسهايي را كه براي اين دستگاه پيكربندي شده است گوش مي دهد.
انواع ديگر گزينه هايي كه در دسترس هستند عبارتند از مواردي كه براي تنظيم تأييد هويت مبتني بر گواهينامه ، گزينه هاي محدود كننده اتصال مانند ClientAliveCountMax و ClientAliveInterval و گزينه هايي مانند ChrootDirectory استفاده مي شود ، كه مي تواند براي قفل كردن ورود به سيستم كاربر به يك فضاي خاص و محيط از پيش تنظيم شده Chroot استفاده شود. .
محدود كردن ورود به سيستم كاربر
ما در بالا به برخي از ابزارهايي كه شما بايد دسترسي كاربران و گروه ها را محدود كنيد ، اشاره كرديم. بياييد كمي با جزئيات بيشتر بحث كنيم.
ابتدايي ترين دستور براي استفاده از اين موارد چيزي شبيه به زير است:
AllowUsers demouser fakeuser madeupuser

همانطور كه مشاهده مي كنيد، ما مي توانيم كاربرهاي مختلفي را از هم جدا كنيم كه در هر يك از اين دستورالعمل ها قرار دارند.
ما همچنين مي توانيم از wild cards استفاده كرده و ورودي ها را نفي كنيم. به عنوان مثال ، اگر مي خواستيم به همه كاربرها به جز “جان” اجازه ورود به سيستم بدهيم ، مي توانيم چيزي شبيه به اين را امتحان كنيم:
AllowUsers * !john
اين نمونه خاص احتمالاً با خط DenyUsers بهتر بيان مي شود:

DenyUsers john
ما همچنين مي توانيم از علامت ? براي مطابقت دقيق با يك حرف استفاده كنيم، به عنوان مثال ميتوانيم از دستور زير استفاده كنيم:

AllowUsers ?im

اين كار اجازه مي دهد تا از حساب هايي مانند “tim” ، “jim” يا “vim” وارد شويد.
با اين حال ما مي توانيم مشخص تر شويم. در هر دو مشخصات كاربر ، مي توانيم از فرم كاربر user@hostname استفاده كنيم تا ورود به مكانهاي منبع خاص مشتري محدود شود. به عنوان مثال ، شما مي توانيد چيزي مانند دستور زير را تايپ كنيد:
AllowUsers demouser@host1.com fakeuser

اين كار باعث مي شود “fakeuser” از هرجاي ديگري وارد سيستم شود ، اما فقط به “demouser” اجازه مي دهد تا از يك هاست مشخص وارد شود.
ما همچنين مي توانيم دسترسي را به صورت ميزبان به ميزبان در خارج از فايل sshd_config از طريق بسته هاي TCP محدود كنيم. اين از طريق فايل هاي /etc/hosts.allow و /etc/hosts.deny پيكربندي ميشود.
به عنوان مثال ، ما مي توانيم دسترسي را به طور خاص بر اساس ترافيك SSH با اضافه كردن خط هايي مانند زير به فايل hosts.allow محدود كنيم:
sshd: .example.com

با فرض اينكه ما در فايل hosts.deny يك خط همراه داريم كه به صورت زير است:
sshd: ALL
اين كار ورود به سيستم را فقط براي افرادي كه از example.com يا يك زير دامنه وارد مي شوند محدود مي كند.
استفاده از گزينه هاي مطابقت براي اضافه كردن استثنائات
ما مي توانيم با استفاده از گزينه هاي “match” گزينه هاي خود را حتي بيشتر كنترل كنيم. گزينه هاي مطابقت با مشخص كردن الگوي معياري كار ميكنند كه تصميم مي گيرند كه گزينه هاي زير استفاده خواهد شد يا خير.
ما يك مطابقت را با استفاده از گزينه Match و سپس مشخص كردن جفت هاي معياري با ارزش كليدي شروع مي كنيم. كليدهاي موجود “كاربر” ، “گروه” ، “ميزبان” و “آدرس” هستند. ما مي توانيم معيارها را با فاصله جدا كنيم و الگوها (user1، user2) را با كاما از هم جدا كنيم. ما همچنين مي توانيم از wild cards و خنثي سازي استفاده كنيم:
Match User !demouser,!fakeuser Group sshusers Host *.example.com

خط بالا فقط در صورتي مطابقت دارد كه كاربر demouser يا fakeuser نباشد ، در صورتي كه كاربر عضو گروه sshusers باشد و در صورت اتصال آن از example.com يا يك زير دامنه استفاده كند.
معيارهاي “آدرس” مي توانند از نماد net Cask CIDR استفاده كنند.
گزينه هايي كه از مشخصات مطابقت پيروي مي كنند بصورت مشروط اعمال مي شوند. دامنه اين گزينه هاي شرطي تا پايان پرونده يا مشخصات مطابقت بعدي است. به همين دليل توصيه مي شود مقادير پيش فرض خود را در بالاي فايل قرار دهيد و استثنائات خود را در انتهاي آن قرار دهيد.

به دليل اين بلوك شرطي ، گزينه هاي موجود تحت مطابقت اغلب بيان ميكنند كه فقط در انطباق فوق اعمال مي شوند. به عنوان مثال ، شرط فوق مي تواند بلوكي مانند اين تحت آن داشته باشد:
Match User !demouser,!fakeuser Group sshusers Host *.example.com
AuthorizedKeysFile /sshusers/keys/%u
PasswordAuthentication yes
X11Forwarding
X11DisplayOffset 15

شما فقط هنگام برخورد با مشخصات انطباق به زير مجموعه گزينه ها دسترسي داريد. براي ديدن ليست كامل ، صفحه sshd_config را ببينيد:
man sshd_config

براي ديدن ليست گزينه هاي موجود ، بخش “مطابقت” را جستجو كنيد.
نتيجه
همانطور كه مشاهده مي كنيد ، مي توانيد مقادير زيادي را در سمت سرور SSH تنظيم كنيد كه در توانايي كاربران براي ورود به سيستم و كيفيت تجربه آنها تأثير مي گذارد. اطمينان حاصل كنيد كه تغييرات خود را قبل از اجراي مقياس گسترده با دقت آزمايش كنيد تا خطاها را پيدا كنيد و اطمينان حاصل كنيد كه محدوديت هاي شما به طور تصادفي روي تعداد كمي از كاربران يا تعداد خيلي زيادي تأثير نمگذارد.
آشنايي با فايل / etc / ssh / sshd_config اولين قدم بزرگ در جهت درك چگونگي كنترل دقيق دسترسي به سرور شماست. و يك مهارت مهم براي هر مدير سيستم لينوكس ميباشد.

مقدمه
WordPress يك سيستم مديريت محتواي منبع باز (CMS) است. WordPress محبوب ترين CMS در جهان است كه به شما امكان مي دهد تا وبلاگ ها و وب سايت هايي را فراتر از پايگاه داده MySQL تنظيم كنيد ، از PHP براي اجراي اسكريپت ها و پردازش محتواي پويا استفاده كنيد.
OpenLiteSpeed ​​ يك سرور وب منبع باز بهينه شده است كه مي توانيد از آن براي مديريت و سرويس وب سايت ها استفاده كنيد. OpenLiteSpeed ​​ داراي برخي ويژگي هاي مفيد است كه آن را به گزينه اي مناسب براي بسياري از نصب ها تبديل مي كند: قوانين بازنويسي سازگار با Apache، يك رابط كاربري مديريت مبتني بر وب و پردازش PHP سفارشي براي بهينه سازي سرور.
اين راهنما روند نصب و تنظيم يك نمونه وردپرس را در Ubuntu 18.04 با استفاده از وب سرور OpenLiteSpeed ​​طي خواهد كرد. از آنجا كه هم WordPress و OpenLiteSpeed ​​مي توانند از طريق يك مرورگر وب مديريت شوند ، اين پيكربندي براي كساني كه دسترسي منظم به بخش SSH ندارند يا كساني كه ممكن است احساس راحتي مديريت يك سرور وب از طريق خط فرمان را نداشته باشند ، ايده آل است.
پيش نيازها
قبل از شروع اين راهنما به موارد زير نياز خواهيد داشت:
يك سرور كه Ubuntu 18.04 را اجرا ميكند با يك ادمين، يك كاربر غير روت و فايروال با استفاده از ufw پيكربندي كرده است. براي تنظيم اين محيط ، آموزش اوليه سرور ما را براي اوبونتو 18.04 دنبال كنيد.
OpenLiteSpeed ​​ بر روي سرور شما نصب شده است. براي راهنمايي در مورد نصب و پيكربندي OpenLiteSpeed ​​به راهنماي ما در مورد نحوه نصب OpenLiteSpeed ​​وب سرور در اوبونتو 18.04 مراجعه كنيد.
MySQL بر روي سرور شما نصب شده است. براي تنظيم اين روش نحوه نصب MySQL را در اوبونتو 18.04 دنبال كنيد.
مرحله 1 – ايجاد يك بانك اطلاعاتي و كاربر بانك اطلاعاتي براي وردپرس
WordPress از MySQL براي مديريت و ذخيره اطلاعات سايت و كاربر استفاده مي كند. شما قبلاً MySQL را نصب كرده ايد ، اما به عنوان يك مرحله مقدماتي به ايجاد يك بانك اطلاعاتي و يك كاربر براي استفاده از وردپرس نياز داريد.
براي شروع كار ، با استفاده از SSH به سرور خود وصل شويد:
ssh sammy @ your_server_IP
سپس وارد حساب ريشه MySQL شويد:

sudo mysql

توجه: اگر مرحله 3 را در پيش نياز آموزش MySQL به پايان رسانده ايد و كاربر root MySQL را براي تأييد اعتبار با افزونه mysql_native_password پيكربندي كرده ايد ، بايد دستور زير را وارد كنيد:
mysql -u root -p

سپس در صورت درخواست رمزعبور كاربر اصلي خود را وارد كنيد.
از تبليغ MySQL ، يك پايگاه داده با دستور زير ايجاد كنيد. در اينجا ، ما اين ديتابيس را براي سادگي وردپرس نام مي گذاريم ، اما شما مي توانيد آن را هرچه دوست داريد نامگذاري كنيد:
CREATE DATABASE wordpress DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci;
سپس ، يك كاربر ايجاد كرده و به آن امتيازات بانك اطلاعاتي كه اخيراً ايجاد كرده ايد بدهيد. باز هم ، مي توانيد هر نامي را به اين كاربر بدهيد ، اما براي سادگي ما آن را wordpressuser مي ناميم. همچنين ، حتماً گذرواژه را به يك رمز عبور قوي با انتخاب خود تغيير دهيد:
GRANT ALL PRIVILEGES ON wordpress.* TO ‘wordpressuser’@’localhost’ IDENTIFIED BY ‘password’;
سپس ، PRUSILEGES FLUSH را اجرا كنيد كه به سرور مي گويد جداول اعطاي امتياز را مجدد لود كند و اعمال تغييرات جديد خود را اجرا كنيد ،:
FLUSH PRIVILEGES;
پس از آن ، مي توانيد اعلان MySQL را ببنديد:
exit
اكنون نصب MySQL خود براي كار با WordPress را انجام داده ايد. در مرحله بعد چند افزونه PHP نصب خواهيم كرد.

مرحله 2 – نصب افزونه هاي اضافي PHP
در آموزش پيش نياز OpenLiteSpeed ​​، بسته lsphp73 را نصب كرديد. اين مجموعه اي از PHP بهينه شده براي OpenLiteSpeed ​​ است كه از LiteSpeed ​​SAPI براي ارتباط با برنامه هاي خارجي استفاده مي كند. بسته به نياز شما ، وردپرس ممكن است نياز به ساير افزونه هاي PHP داشته باشد تا بتواند به دلخواه عمل كند.

براي نصب برخي افزونه هاي PHP كه معمولاً با WordPress استفاده مي شود ، دستور زير را اجرا كنيد:
sudo apt install lsphp73-common lsphp73-curl lsphp73-imagick lsphp73-imap lsphp73-json lsphp73-memcached lsphp73-mysql lsphp73-opcache lsphp73-redis
توجه: بسته هاي اين دستور ممكن است تمام موارد استفاده را پوشش ندهد. براي يك ليست كامل از افزونه هاي PHP 7.3 موجود از مخزن LiteSpeed ​​كه در آموزش پيش نياز به سرور خود اضافه كرده ايد ، به Wiki LiteSpeed ​​مراجعه كنيد.
پس از اين ، مي توانيد به سمت دانلود و تنظيم وردپرس در سرور خود برويد.
مرحله 3 – دانلود وردپرس
اكنون كه نرم افزار سرور شما پيكربندي شده است ، مي توانيد WordPress را نصب و تنظيم كنيد. به ويژه به دلايل امنيتي ، هميشه توصيه مي شود كه آخرين نسخه وردپرس را مستقيماً از سايت خودشان دريافت كنيد.
به يك ديركتوري قابل نوشتار برويد و سپس نسخه فشرده شده را با تايپ كردن دستور زير دانلود كنيد:
cd /tmp
curl -O https://wordpress.org/latest.tar.gz
براي ايجاد ساختار دايركتوري وردپرس ، فايل فشرده شده را استخراج كنيد:
tar xzvf latest.tar.gz
ما اين پرونده ها را لحظه به لحظه به ريشه سند منتقل خواهيم كرد ، اما ابتدا چند فايل و فهرست را ايجاد خواهيم كرد كه نصب وردپرس به آنها بستگي دارد.
OpenLiteSpeed ​​ از فايل هاي .htaccess پشتيباني مي كند. اين براي اهداف ما مهم است ، از آنجا كه وردپرس
از فايلهاي .htaccess براي ايجاد و مديريت پرونده هاي ثابت استفاده مي كند.
يك فايل .htaccess ساختگي اضافه كنيد تا بعداً براي استفاده وردپرس در دسترس باشد:
touch /tmp/wordpress/.htaccess

سپس ، فايل پيكربندي نمونه را بر روي نام خانوادگي كه وردپرس ميخواند، كپي كنيد:
cp /tmp/wordpress/wp-config-sample.php /tmp/wordpress/wp-config.php
علاوه بر اين ، دايركتوري upgrade را ايجاد كنيد تا وردپرس هنگام تلاش براي انجام اين كار به تنهايي و به دنبال بروزرساني در نرم افزار خود ، به مشكلات مربوط به مجوزها برخورد نكند:

mkdir /tmp/wordpress/wp-content/upgrade
سپس كل محتواي فهرست را در روت سند خود كپي كنيد.OpenLiteSpeed ​​ با يك ميزبان مجازي پيش فرض به نام Example در ديركتوري / usr / local / lsws / قرار دارد. روت سند براي ميزبان مجازي Example زيرمجموعه html است:
sudo cp -a /tmp/wordpress/. /usr/local/lsws/Example/html/wordpress
توجه كنيد كه اين دستور شامل يك نقطه در انتهاي فهرست منبع است تا نشان دهد كه همه چيزهاي داخل ديركتوري بايد كپي شوند ، از جمله پرونده هاي مخفي (مانند پرونده .htaccess كه ايجاد كرديد):
با اين كار ، شما وردپرس را با موفقيت روي سرور وب خود نصب كرده ايد و برخي از مراحل اوليه تنظيمات را انجام داده ايد. در مرحله بعد ، ما تغييرات ديگري را در پيكربندي انجام خواهيم داد كه امتيازات وردپرس را براي عملكرد ايمن و دسترسي به بانك اطلاعاتي MySQL و حساب كاربري كه قبلاً ايجاد كرده ايد به شما مي دهد.
مرحله 4 – پيكربندي دايركتوري وردپرس
قبل از اينكه بتوانيم فرآيند راه اندازي مبتني بر وب را براي وردپرس طي كنيم ، بايد برخي موارد را در دايركتوري وردپرس خود تنظيم كنيم.
با دادن مالكيت كليه فايل هاي موجود در ديركتوري به كاربر nobody و گروه nogroup ، كه وب سرور OpenLiteSpeed ​​بصورت پيش فرض اجرا مي كند ، شروع كنيد. دستور chown زير به OpenLiteSpeed ​​امكان خواندن و نوشتن فايل ها در دايركتوري وردپرس را اعطا مي كند ، و اين امكان را براي سرويس دهي به وب سايت و انجام به روز رساني هاي خودكار فراهم مي كند:
sudo chown -R nobody:nogroup /usr/local/lsws/Example/html/wordpress
براي تنظيم مجوزهاي صحيح در دايركتوري ها و فايل هاي وردپرس ، دو دستور find اجرا كنيد:
sudo find /usr/local/lsws/Example/html/wordpress/ -type d -exec chmod 750 {} ;
sudo find /usr/local/lsws/Example/html/wordpress/ -type f -exec chmod 640 {} ;
اينها بايد مجوزهاي معقولي براي شروع باشد ، اگرچه برخي از افزونه ها و رويه ها ممكن است نياز به ترفندهاي اضافي داشته باشند.
پس از اين ، شما بايد تغييراتي در پرونده اصلي پيكربندي WordPress انجام دهيد.
با باز كردن فايل ، اولين هدف شما تنظيم برخي كليدهاي مخفي براي ايجاد امنيت براي نصب شما خواهد بود. WordPress يك مولد مطمئن براي اين مقادير فراهم مي كند به طوري كه ديگر نيازي به تلاش براي دستيابي به مقادير خوب از خودتان نيست. اينها فقط به صورت داخلي استفاده مي شود ، بنابراين به مقادير پيچيده و ايمن در اينجا آسيب نمي رساند.
براي گرفتن مقادير ايمن از مولد كليد مخفي WordPress ، تايپ كنيد:
curl -s https://api.wordpress.org/secret-key/1.1/salt/
شما به مقادير منحصر به فردي بر مي گرديد كه چيزي شبيه به اين است:

هشدار! مهم است كه هر بار درخواست مقادير منحصر به فرد كنيد. مقادير نشان داده شده در زير را كپي نكنيد!

خروجي
define(‘AUTH_KEY’, ‘1jl/vqfs define(‘SECURE_AUTH_KEY’, ‘E2N-h2]Dcvp+aS/p7X DO NOT COPY THESE VALUES {Ka(f;rv?Pxf})CgLi-3’);
define(‘LOGGED_IN_KEY’, ‘W(50,{W^,OPB%PB define(‘NONCE_KEY’, ‘ll,4UC)7ua+8سرور وب داده شده است كه در هر جا لازم است بنويسيم، مي توانيم به طور صريح روش سيستم فايل را به direct تنظيم كنيم. عدم تنظيم اين با تنظيمات فعلي ما منجر به اعلان وردپرس براي اعتبار FTP در هنگام برخي عملكردهاي خاص ميشود. اين تنظيمات مي تواند در زير تنظيمات اتصال ديتابيس يا هر جاي ديگر فايل اضافه شود: /var/www/wordpress/wp-config.php . . . define(‘DB_NAME’, ‘wordpress’); /** MySQL database username */ define(‘DB_USER’, ‘wordpressuser’); /** MySQL database password */ define(‘DB_PASSWORD’, ‘password’); . . . define(‘FS_METHOD’, ‘direct’); هنگامي كه كارتان تمام شد، فايل را ذخيره كنيد و ببنديد. در اين مرحله ، وردپرس كاملاً در سيستم شما پيكربندي نشده است ، زيرا هنوز لازم است قبل از شروع انتشار مطالب ، چند كار نهايي را اعمال كنيد. براي انجام اين كار ، ابتدا لازم است چند تغيير تنظيمات در نصب OpenLiteSpeed خود اعمال كنيد. مرحله 6 – پيكربندي OpenLiteSpeed در حال حاضر ، شما WordPress را در سرور Ubuntu خود نصب كرده ايد ، اما نصب OpenLiteSpeed ​​شما هنوز براي ارائه آن تنظيم نشده است. در اين مرحله ، ما به رابط اجرايي OpenLiteSpeed ​​دسترسي خواهيم داشت و چند تغيير در پيكربندي سرور شما ايجاد مي كنيم. در مرورگر وب مورد نظر خود، به رابط اداري OpenLiteSpeed ​​برويد. مي توانيد اين را با وارد كردن آدرس IP عمومي سرور خود يا نام دامنه مرتبط با آن ، و به دنبال آن: 7080 در نوار آدرس مرورگر خود بيابيد: https: // server_domain_or_IP: 7080 در آنجا به شما يك صفحه ورود به سيستم ارائه مي شود. نام كاربري و رمز عبوري را كه در آموزش پيش نياز OpenLiteSpeed ​​تعريف كرده ايد وارد كنيد: از كنسول OpenLiteSpeed ​​، در منوي نوار كناري سمت چپ ، بر روي تنظيمات سرور كليك كنيد. سپس به سربرگ External App برويد ، رديف برنامه LiteSpeed ​​SAPI را پيدا كنيد و بر روي دكمه Edit آن كليك كنيد: به ياد بياوريد كه در پيش نياز آموزش OpenLiteSpeed ​​، بسته lsphp73 را نصب كرديد ، تلفيقي از PHP بهينه سازي شده براي كار با OpenLiteSpeed ​​از طريق LiteSpeed ​​SAPI. با اين حال ، تنظيمات پيش فرض در صفحه External App به lsphp اشاره دارد نه lsphp73. به همين دليل ، نصب OpenLiteSpeed ​​شما قادر به اجراي صحيح اسكريپت هاي PHP نيست. براي تصحيح اين امر ، قسمت Name را به lsphp73 تغيير دهيد ، قسمت آدرس را به uds: //tmp/lshttpd/lsphp73.sock تغيير دهيد و قسمت Command را به SERVER_ROOT / lsphp73 / bin / lsphp: پس از ايجاد آن تغييرات ، روي آيكون save در گوشه سمت راست بالاي كادر LiteSpeed ​​SAPI App كليك كنيد. سپس، در منوي سمت چپ روي Virtual Hosts كليك كنيد. در صفحه Virtual Hosts ميزبان مجازي مورد نظر خود را پيدا كنيد و بر روي نماد View آن كليك كنيد. در اينجا ، ما از هاست مجازي مثال پيش فرض استفاده خواهيم كرد: به سربرگ General هاست مجازي برويد. در آنجا بخش General را پيدا كنيد و روي دكمه edit آن كليك كنيد: OpenLiteSpeed ​​ براي ارائه خدمات به دنبال محتويات Document Root ميگردد. از آنجا كه تمام مطالب و فايل هاي وردپرس شما در ديركتوري وردپرس كه قبلا ايجاد شده ذخيره مي شوند، قسمت Document Root را به روز كنيد تا به آن ديركتوري راهنمايي كنيد. براي انجام اين كار ، تنها كاري كه بايد انجام دهيد اضافه كردن وردپرس / به پايان مقدار پيش فرض است: براي ذخيره اين تغيير، روي آيكون save كليك كنيد. در مرحله بعد ، بايد پرونده هاي index.php را فعال كنيد تا از آنها براي پردازش درخواست هايي كه توسط پرونده هاي استاتيك مديريت نمي شوند ، استفاده شود. با اين كار منطق اصلي وردپرس به درستي كار مي كند. در حالي كه هنوز در تب General هستيد، براي يافتن بخش Index Files به پايين برويد و بر روي نماد edit آن كليك كنيد: در قسمت Index Files ، index.html را با index.php پيش ببريد. با قرار دادن index.php قبل از index.html ، به فايلهاي شاخص PHP اجازه مي دهيد كه اولويت داشته باشند. پس از به روزرساني اين قسمت ، مانند عكس خواهد بود قبل از ادامه ، روي آيكون save كليك كنيد. در مرحله بعد ، به سربرگ Rewrite هاست مجازي برويد. بخش Rewrite Control را پيدا كنيد و دكمه ويرايش را فشار دهيد: با كليك بر روي دكمه هاي شعاعي مربوطه ، هر دو گزينه Enable Rewrite و Auto Load را از گزينه هاي .htaccess روي Yes بگذاريد. پيكربندي دستورالعمل هاي بازنويسي در اين روش به شما امكان مي دهد از نصب مجدد لينك ها در نصب وردپرس خود استفاده كنيد: بعد از انجام تغييرات ، روي ذخيره كليك كنيد. هاست مجازي پيش فرض كه همراه با نصب OpenLiteSpeed ​​است شامل برخي از نواحي محافظت شده با رمز عبور براي نمايش ويژگي هاي تأييد اعتبار كاربر OpenLiteSpeed. است. WordPress شامل مكانيزم هاي تأييد اعتبار خاص خود است و ما از هويت مبتني بر پرونده موجود در OpenLiteSpeed ​​استفاده نخواهيم كرد. براي به حداقل رساندن بخش هاي پيكربندي انحرافي فعال در نصب وردپرس ما بايد از اين موارد خلاص شويم. ابتدا بر روي زبانه Security كليك كرده و سپس بر روي دكمه Delete كنار SampleProtectedArea در جدول Realms List كليك كنيد: از شما خواسته مي شود حذف را تأييد كنيد. براي ادامه بر روي delete كليك كنيد در مرحله بعد ، روي سربرگ Context كليك كنيد. در Context List ، محتواي /protected/ را كه با قلمرو امنيتي كه اخيراً حذف كرديد مرتبط بود را حذف كنيد: مجدداً بايد با كليك كردن روي delete ، حذف را تأييد كنيد. شما مي توانيد با اطمينان با استفاده از همان تكنيك ، همه متن هاي ديگر را پاك كنيد ، زيرا ما به آنها احتياج نخواهيم داشت. ما به طور خاص محتواي /protected/ متن را حذف كرديم زيرا در غير اين صورت خطايي به دليل حذف قلمرو امنيت مرتبط با آن ايجاد مي شود (كه ما فقط در تب Security حذف كرده ايم.) پس از آن ، در گوشه سمت راست بالاي كنسول OpenLiteSpeed ​​، آيكون Graceful Restart را فشار دهيد. با اين كار سرور OpenLiteSpeed ​​ دوباره راه اندازي مي شود و باعث مي شود تغييراتي كه ايجاد كرده ايد به مرحله اجرا برسد: با اين كار ، سرور OpenLiteSpe شما كاملاً پيكربندي شده است. اكنون آماده تنظيم وردپرس در مرورگر خود هستيد. مرحله 7 – تكميل نصب از طريق واسط وردپرس اكنون كه پيكربندي سرور كامل شد ، مي توانيم نصب را از طريق رابط وب انجام دهيم. در مرورگر وب خود ، به نام دامنه سرور يا آدرس IP عمومي خود برويد: http: // server_domain_or_IP زباني را كه مي خواهيد استفاده كنيد انتخاب كنيد: در مرحله بعد به صفحه اصلي تنظيمات خواهيد رسيد. يك نام براي سايت وردپرس خود انتخاب كنيد و يك نام كاربري را انتخاب كنيد (توصيه مي شود براي اهداف امنيتي چيزي مانند “ادمين” انتخاب نكنيد). رمزعبور قوي به صورت خودكار ايجاد مي شود. اين رمز عبور را ذخيره كنيد يا يك رمزعبور قوي ديگر را انتخاب كنيد. آدرس ايميل خود را وارد كنيد و انتخاب كنيد آيا مي خواهيد موتورهاي جستجو را از ايندكس كردن سايت خود منع كنيد: پس از آماده شدن ، روي دكمه Install WordPress كليك كنيد. شما به صفحه اي منتهي مي شويد كه وارد سيستم شويد: پس از ورود به سيستم ، شما به داشبورد مديريت وردپرس منتقل مي شويد: از داشبورد ، مي توانيد تغييراتي در تم سايت خود و انتشار محتواي آن ايجاد كنيد. نتيجه با تكميل اين راهنما ، يك نمونه وردپرس را روي سرور اوبونتو 18.04 كه OpenLiteSpeed ​​را اجرا مي كند ، نصب و پيكربندي كرديد. برخي مراحل متداول بعدي بايد براي تنظيمات پيوند مجدد پست هاي شما انتخاب شوند (كه مي توانيد در Settings > Permalinksپيدا كنيد) يا انتخاب يك تم جديد (در Appearance > Themes). اگر اين اولين باري است كه از WordPress استفاده مي كنيد ، كمي رابط را جستجو كنيد تا با CMS جديد خود آشنا شويد.
براي افزايش امنيت سايت جديد وردپرس خود ، توصيه مي كنيم آن را پيكربندي كنيد تا با SSL كار كند تا بتواند از طريق HTTPS محتوا را ارائه دهد. براي نصب LetsEncrypt و تنظيم اين آموزش ، از اسناد OpenLiteSpeed ​​بازديد كنيد.

Apache Kafka يك كارگزار پيام توزيع شده محبوب است كه براي مديريت حجم زيادي از داده هاي زمان-واقعي طراحي شده است. خوشه كافكا بسيار مقياس پذير و داراي تحمل خطا است و همچنين نسبت به ساير واسطه هاي پيام مانند ActiveMQ و RabbitMQ از توان بسيار بالاتري برخوردار است. اگرچه معمولاً از آن به عنوان يك سيستم پيام رسان انتشار / اشتراك استفاده مي شود ، بسياري از سازمان ها نيز از آن براي جمع آوري ورود به سيستم استفاده مي كنند زيرا فضاي ذخيره سازي مداوم را براي پيام هاي منتشر شده ارائه مي دهد.
يك سيستم پيام رساني انتشار / اشتراك به يك يا چند توليد كننده اجازه مي دهد پيام ها را بدون در نظر گرفتن تعداد مصرف كنندگان يا نحوه پردازش پيام ها منتشر كنند. متقاضيان داراي اشتراك در مورد به روزرساني ها و ايجاد پيام هاي جديد بطور خودكار مطلع مي شوند. اين سيستم نسبت به سيستم هايي كه مشتري ها بطور دوره اي در مورد آن نظرسنجي مي شوند تا مشخص شود كه آيا پيام هاي جديد در دسترس است يا خير، بسيار كارآمدتر و مقياس پذير است.
در اين آموزش ، Apache Kafka 2.1.1 را به صورت ايمن روي سرور Debian 10 نصب و پيكربندي مي كنيد ، سپس با توليد و استفاده از يك پيام Hello World راه اندازي خود را تست مي كنيد. سپس مي توانيد KafkaT را به صورت اختياري براي نظارت بر كافكا نصب كنيد و يك خوشه چند گره كافكا را تنظيم كنيد.
پيش نيازها
براي دنبال كردن ، به موارد زير نياز خواهيد داشت:
يك سرور Debian 10 با حداقل 4 گيگابايت رم و يك كاربر غير ريشه با امتيازات سودو. در صورتي كه كاربر غير ريشه تنظيم نكرده ايد، مراحل ذكر شده در راهنماي راه اندازي سرور اوليه براي Debian 10 را دنبال كنيد.
OpenJDK 11 روي سرور شما نصب شده است. براي نصب اين نسخه ، دستورالعمل هاي نصب Java را با Apt در Debian 10 در مورد نصب نسخه هاي خاص OpenJDK دنبال كنيد. كافكا در جاوا نوشته شده است ، بنابراين به JVM نياز دارد.
توجه: نصب هاي بدون رم 4 گيگابايتي ممكن است باعث شود سرويس كافكا از كار بيفتد، در حالي كه دستگاه مجازي جاوا (JVM) در هنگام راه اندازي يك استثناء Out Of Memory را به همراه داشته باشد.
مرحله 1 – ايجاد كاربر براي كافكا
از آنجا كه كافكا مي تواند درخواست ها را از طريق شبكه انجام دهد ، بهترين كار براي ايجاد يك كاربر اختصاصي براي آن است. در صورت به خطر افتادن سرور كافكا ، اين كار آسيب به دستگاه Debian شما را به حداقل مي رساند. در اين مرحله شما كاربر اختصاصي كافكا را ايجاد خواهيد كرد.
به عنوان كاربر sudo غير ريشه خود وارد شويد ، با دستور useradd كاربري بنام kafka بسازيد:
sudo useradd kafka -m
فلگ -m تضمين مي كند كه يك هوم ديركتوري براي كاربر ايجاد مي شود. اين هوم ديركتوري، / home / kafka ، بعداً به عنوان ديركتوري فضاي كاري شما براي اجراي دستورات عمل خواهد كرد.

رمز عبور را با استفاده از passwd تنظيم كنيد:
sudo passwd kafka
رمز عبوري را كه مي خواهيد براي اين كاربر استفاده كنيد وارد كنيد.
در مرحله بعدي ، كاربر كافكا را با دستور adduser به گروه سودو اضافه كنيد ، تا امتيازات لازم براي نصب وابستگي كافكا را داشته باشد:
sudo adduser kafka sudo
كاربر kafka شما اكنون آماده است. با استفاده از su وارد اين حساب شويد:
su -l kafka
اكنون كه كاربر اختصاصي كافكا را ايجاد كرده ايد ، مي توانيد به دانلود و استخراج باينري هاي كافكا برويد.
مرحله 2 – دانلود و استخراج باينري هاي كافكا
در اين مرحله، باينري هاي كافكا را در پوشه هاي اختصاصي در ديركتوري هوم كاربر kafka خود دانلود و اكستركت مي كنيد.
براي شروع ، دايركتوري را در / home / kafka با نام Downloads براي ذخيره دانلودهاي خود ايجاد كنيد:
mkdir ~/Downloads
در مرحله بعدي، حلقه را با استفاده از apt-get نصب كنيد تا بتوانيد فايلهاي از راه دور را دانلود كنيد:
sudo apt-get update && sudo apt-get install curl
در صورت درخواست، Y را تايپ كنيد تا دانلود curl را تأييد كنيد.
پس از نصب Curl ، از آن براي دانلود باينري هاي كافكا استفاده كنيد:
curl “https://archive.apache.org/dist/kafka/2.1.1/kafka_2.11-2.1.1.tgz” -o ~/Downloads/kafka.tgz
دايركتوري به نام kafka ايجاد كنيد و به اين فهرست تغيير دهيد. اين دايركتوري پايه نصب كافكا خواهد بود:
mkdir ~/kafka && cd ~/kafka
با استفاده از دستور tar ، آرشيوي را كه دانلود كرده ايد استخراج كنيد:
tar -xvzf ~/Downloads/kafka.tgz –strip 1
شما فلگ –strip 1 را براي اطمينان از استخراج محتواي بايگاني در ~ / kafka / و نه در ديركتوري ديگري در داخل آن ، مانند ~ / kafka / kafka_2.12-2.1.1 / مشخص كرده ايد.
اكنون كه باينري ها را با موفقيت دانلود و استخراج كرده ايد ، مي توانيد پيكربندي كافكا را انجام دهيد تا امكان حذف موضوع فراهم شود.
مرحله 3 – پيكربندي سرور كافكا
رفتار پيش فرض كافكا به ما اجازه نمي دهد تا عنوان، دسته بندي، گروه يا نام فيد را براي انتشار پيام ها حذف كنيم. براي تغيير اين، پرونده پيكربندي را ويرايش مي كنيد.
گزينه هاي پيكربندي كافكا در server.properties مشخص شده است. اين پرونده را با nano يا ويرايشگر مورد علاقه خود باز كنيد:
nano ~/kafka/config/server.properties
بياييد تنظيماتي را اضافه كنيم كه به ما امكان حذف عناوين كافكا را مي دهد. خط هايلايت شده زير را در زير فايل اضافه كنيد:
~/kafka/config/server.properties
…
group.initial.rebalance.delay.ms

delete.topic.enable = true

فايل را ذخيره كنيد و از nano خارج شويد. اكنون كه Kafka را پيكربندي كرده ايد، مي توانيد براي راه اندازي و فعال كردن كافكا در هنگام راه اندازي فايل هاي واحد systemed ايجاد كنيد.
مرحله 4 – ايجاد فايلهاي واحد سيستمي و راه اندازي سرور كافكا
در اين بخش فايلهاي واحد سيستمي براي سرويس كافكا ايجاد مي كنيد. اين به شما كمك مي كند تا خدمات متداول مانند شروع، متوقف كردن و راه اندازي مجدد كافكا را به روشي سازگار با ساير سرويس هاي لينوكس انجام دهيد.
ZooKeeper سرويسي است كه كافكا براي مديريت وضعيت و تنظيمات خوشه اي از آن استفاده مي كند. معمولاً در سيستم هاي توزيع شده به عنوان يك جزء اساسي مورد استفاده قرار مي گيرد. در اين آموزش از Zookeeper براي مديريت اين جنبه هاي كافكا استفاده خواهيد كرد. اگر تمايل داريد اطلاعات بيشتري در مورد آن بدانيد ، به مطالب ZooKeeper رسمي ما مراجعه كنيد.
ابتدا فايل واحد را براي zookeeper ايجاد كنيد:
sudo nano /etc/systemd/system/zookeeper.service
تعريف واحد زير را در پرونده وارد كنيد:
/etc/systemd/system/zookeeper.service
[Unit]
Requires=network.target remote-fs.target
After=network.target remote-fs.target

[Service]
Type=simple
User=kafka
ExecStart=/home/kafka/kafka/bin/zookeeper-server-start.sh /home/kafka/kafka/config/zookeeper.properties
ExecStop=/home/kafka/kafka/bin/zookeeper-server-stop.sh
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

بخش [Unit] مشخص مي كند كه ZooKeeper به شبكه نياز دارد و سيستم فايل قبل از شروع آن آماده است.
در بخش [Service] مشخص شده است كه systemd براي شروع و متوقف كردن سرويس بايد از پرونده هاي zookeeper-server-start.sh و zookeeper-server-stop.sh استفاده كند. همچنين مشخص مي كند در صورت خارج شدن غيرطبيعي ، ZooKeeper بايد به طور خودكار مجدداً راه اندازي شود.
در مرحله بعد، فايل سرويس systemd را براي kafka ايجاد كنيد:
sudo nano /etc/systemd/system/kafka.service

تعريف واحد زير را در پرونده وارد كنيد:
/etc/systemd/system/kafka.service
[Unit]
Requires=zookeeper.service
After=zookeeper.service

[Service]
Type=simple
User=kafka
ExecStart=/bin/sh -c ‘/home/kafka/kafka/bin/kafka-server-start.sh /home/kafka/kafka/config/server.properties > /home/kafka/kafka/kafka.log 2>&1’
ExecStop=/home/kafka/kafka/bin/kafka-server-stop.sh
Restart=on-abnormal

[Install]
WantedBy=multi-user.target

بخش [Unit] مشخص مي كند كه اين فايل واحد به zookeeper.service بستگي دارد. اين امر اطمينان مي دهد كه با شروع سرويس كافكا ، zookeeper به طور خودكار شروع مي شود.
در بخش [Service] مشخص شده است كه systemd بايد براي شروع و توقف سرويس از فايلهاي پوسته kafka-server-start.sh و kafka-server-stop.sh استفاده كند. همچنين مشخص مي كند در صورت خارج شدن غير عادي ، كافكا بايد به طور خودكار مجدداً راه اندازي شود.
اكنون كه واحدها تعريف شده اند ، كافكا را با دستور زير شروع كنيد:
sudo systemctl start kafka
براي اطمينان از شروع موفقيت آميز سرور ، گزارش هاي ژورنال را براي واحد kafka بررسي كنيد:
sudo journalctl -u kafka
خروجي مشابه موارد زير را مشاهده خواهيد كرد:
Mar 23 13:31:48 kafka systemd[1]: Started kafka.service.

اكنون يك سرور كافكا روي درگاه 9092 داريد كه درگاه پيش فرض براي كافكا است.
شما سرويس kafka را شروع كرده ايد ، اما اگر مي خواهيد سرور خود را دوباره راه اندازي كنيد ، هنوز به طور خودكار شروع نمي شود. براي فعال كردن kafka در بوت سرور ، اين سرور را اجرا كنيد:
sudo systemctl enable kafka
اكنون كه سرويس ها را شروع و فعال كرده ايد ، زمان آن رسيده است كه نصب را بررسي كنيد.
مرحله 5 – تست نصب
بياييد پيام Hello World را منتشر و استفاده كنيم تا مطمئن شويم كه سرور كافكا به درستي رفتار مي كند. انتشار پيام در كافكا به موارد زير بستگي دارد:
تهيه كننده، كه امكان انتشار سوابق و داده ها به عناوين را فراهم مي كند.
مصرف كننده، كه پيام ها و داده ها را از عناوين مي خواند.
ابتدا با تايپ كردن دستور زير عنواني به نام TutorialTopic ايجاد كنيد:
~/kafka/bin/kafka-topics.sh –create –zookeeper localhost:2181 –replication-factor 1 –partitions 1 –topic TutorialTopic
مي توانيد با استفاده از اسكريپت kafka-console-producer.sh يك تهيه كننده از خط فرمان ايجاد كنيد. اين تهيه كننده نام ميزبان ، پورت و نام عنوان سرور كافكا را به عنوان آرگومان ميشناسد.

رشته Hello, World را با تايپ كردن دستور زير براي عنوان TutorialTopic منتشر كنيد:
echo “Hello, World” | ~/kafka/bin/kafka-console-producer.sh –broker-list localhost:9092 –topic TutorialTopic > /dev/null
فلگ – broker-list ليست كارگزاران پيام براي ارسال پيام به آن ها كه در اين مورد localhost: 9092 است را تعيين مي كند. –topic موضوع را به عنوان TutorialTopic تعيين مي كند.
در مرحله بعد ، مي توانيد با استفاده از اسكريپت kafka-console-consumer.sh يك مصرف كننده كافكا ايجاد كنيد. انتظار مي رود نام ميزبان و پورت سرور ZooKeeper و نام تاپيك به عنوان آرگومان باشد.
دستور زير از پيام هاي TutorialTopic استفاده مي كند. توجه داشته باشيد كه از فلگ –from-beginning استفاده كنيد كه امكان استفاده از پيام هايي را كه قبل از شروع مصرف كننده منتشر شده است ، فراهم كند:
~/kafka/bin/kafka-console-consumer.sh –bootstrap-server `localhost:9092` –topic TutorialTopic –from-beginning
–bootstrap-server ليستي از ورودي ها به خوشه كافكا را ارائه مي دهد. در اين حالت ، از localhost استفاده مي كنيد: 9092.
Hello, World را در ترمينال خود مشاهده خواهيد كرد:
خروجي
Hello, World

اين اسكريپت همچنان اجرا مي شود و منتظر انتشار پيام هاي بيشتري براي موضوع خواهد بود. با خيال راحت يك ترمينال جديد باز كنيد و يك تهيه كننده راه اندازي كنيد تا چند پيام ديگر انتشار دهد. شما بايد همه آنها را در خروجي مصرف كننده ببينيد. اگر مي خواهيد در مورد نحوه استفاده از كافكا اطلاعات بيشتري كسب كنيد ، به اطلاعات موجود در لينك كافكا رسمي مراجعه كنيد.
وقتي آزمايش انجام شد ، CTRL + C را فشار دهيد تا اسكريپت مصرف كننده متوقف شود. اكنون كه نصب را آزمايش كرده ايد ، مي توانيد براي اجراي بهتر خوشه كافكا ، به نصب KafkaT برويد.
مرحله 6 – نصب KafkaT (اختياري)
KafkaT ابزاري از Airbnb است كه مشاهده جزئيات مربوط به خوشه كافكا و انجام برخي كارهاي اجرايي از خط فرمان را براي شما آسانتر مي كند. از آنجا كه اين يك Ruby gem است ، براي استفاده از آن به Ruby نياز خواهيد داشت. براي ساختن ساير gemها كه به آن بستگي دارد ، به بسته build-essential نيز احتياج خواهيد داشت. آنها را با استفاده از apt نصب كنيد:
sudo apt install ruby ruby-dev build-essential
اكنون مي توانيد KafkaT را با استفاده از دستور gem نصب كنيد:
sudo CFLAGS=-Wno-error=format-overflow gem install kafkat
گزينه CFLAGS = -Wno-error = format-overflow هشدارهاي فرمت بيش از حد را غيرفعال مي كند و براي gem ZooKeeper ، كه وابسته به KafkaT است ، لازم ميباشد.

KafkaT از .kafkatcfg به عنوان فايل پيكربندي براي تعيين نصب و ورود به فهرست سرورهاي كافكا استفاده مي كند. همچنين بايد داراي ورودي باشد كه KafkaT را به عنوان مثال ZooKeeper به شما نشان دهد.
يك فايل جديد با نام .kafkatcfg ايجاد كنيد:
nano ~/.kafkatcfg
خطوط زير را اضافه كنيد تا اطلاعات لازم در مورد سرور كافكا و مثال Zookeeper خود را مشخص كنيد:
~/.kafkatcfg
{
“kafka_path”: “~/kafka”,
“log_path”: “/tmp/kafka-logs”,
“zk_path”: “localhost:2181”
}

اكنون آماده استفاده از كافكا هستيد. براي شروع ، در اينجا نحوه استفاده از آن براي مشاهده جزئيات مربوط به همه پارتيشن هاي كافكا آورده شده است:
kafkat partitions
خروجي زير را مشاهده خواهيد كرد:
Output
Topic Partition Leader Replicas ISRs
TutorialTopic 0 0 [0] [0]
__consumer_offsets 0 0 [0] [0]
…

اين خروجي TutorialTopic و همچنين __consumer_offsets يك عنوان داخلي كه توسط كافكا براي ذخيره اطلاعات مربوط به مشتري استفاده مي شود ، نشان مي دهد. با خيال راحت مي توانيد خطوط شروع شده با __consumer_offsets را ناديده بگيريد.
براي كسب اطلاعات بيشتر در مورد KafkaT ، به منبع GitHub آن مراجعه كنيد.
اكنون كه KafkaT را نصب كرديد ، مي توانيد Kafka را به صورت اختياري بر روي خوشه اي از سرورهاي Debian 10 تنظيم كنيد تا يك خوشه چند گره ايجاد شود.
مرحله 7 – تنظيم يك خوشه چند گره (اختياري)
اگر مي خواهيد با استفاده از سرورهاي Debian 10 بيشتر ، يك خوشه چند كاره ايجاد كنيد، مرحله 1 ، مرحله 4 و مرحله 5 را روي هر يك از ماشين هاي جديد تكرار كنيد. علاوه بر اين، براي پرونده هاي ~ / kafka / config / server.properties تغييرات زير را انجام دهيد:

مقدار ويژگي broker.id را طوري تغيير دهيد كه در كل خوشه بي نظير باشد. اين ويژگي به طور منحصر به فرد هر سرور موجود در خوشه را مشخص مي كند و مي تواند هر رشته اي را به عنوان مقدار آن داشته باشد. به عنوان مثال ، “server1” ، “server2” و غيره ، به عنوان شناساگر مفيد خواهند بود.
مقدار ويژگي zookeeper.connect را به گونه اي تغيير دهيد كه همه گره ها به همان مثال ZooKeeper اشاره كنند. اين ويژگي آدرس نمونه ZooKeeper را مشخص مي كند و از قالب : پيروي مي كند. براي اين آموزش ، شما از your_first_server_IP: 2181 استفاده خواهيد كرد و your_first_server_IP را با آدرس IP سرور Debian 10 كه قبلاً تنظيم كرده ايد جايگزين كنيد.
اگر مي خواهيد چندين نمونه ZooKeeper براي خوشه خود داشته باشيد ، مقدار ويژگي zookeeper.connect در هر گره بايد يك رشته يكسان با كاما باشد كه در آن آدرس هاي IP و شماره پورت همه موارد ZooKeeper را نشان مي دهد.
توجه: اگر يك فايروال داريد كه روي سرور Debian 10 با نصب Zookeeper فعال شده است ، حتما پورت 2181 را باز كنيد تا اجازه ورود از ساير گره هاي خوشه را دريافت كنيد.
مرحله 8 – محدود كردن كاربر كافكا
اكنون كه تمام مراحل نصب انجام شده است ، مي توانيد امتيازات ادمين كاربر kafka را حذف كنيد. قبل از انجام اين كار ، مانند هر كاربر سودو غير ريشه خارج شويد و دوباره وارد سيستم شويد. اگر هنوز همان بخش شل را اجرا مي كنيد كه اين آموزش را با آن شروع كرده ايد ، فقط exit تايپ كنيد.
كاربر كافكا را از گروه سودو حذف كنيد:
sudo deluser kafka sudo
براي بهبود بيشتر امنيت سرور كافكا ، رمزعبور كاربر kafka را با استفاده از دستور passwd قفل كنيد. اين اطمينان مي دهد كه هيچ كس نمي تواند با استفاده از اين حساب به طور مستقيم وارد سرور شود:
sudo passwd kafka -l
در اين مرحله فقط كاربر root يا يك كاربر sudo مي توانند با وارد كردن دستور زير به عنوان kafka وارد شوند:
sudo su – kafka
در آينده اگر مي خواهيد قفل آن را باز كنيد ، از passwd با گزينه -u استفاده كنيد:
sudo passwd kafka -u
شما اكنون با موفقيت امتيازات ادمين كاربري kafka را محدود كرده ايد.
نتيجه
اكنون Apache Kafka به طور ايمن روي سرور Debian شما اجرا شده است. شما مي توانيد با ايجاد تهيه كنندگان و مصرف كنندگان از بين مشتري هاي كافكا ، كه براي اكثر زبان هاي برنامه نويسي در دسترس است، از آن در پروژه هاي خود استفاده كنيد. براي كسب اطلاعات بيشتر در مورد كافكا، همچنين مي توانيد با آپاچي كافكا مشورت كنيد.

مقدمه
با حركت ابزارهاي توسعه دهنده به سمت cloud ، ساخت و تطبيق پلتفرم هاي cloud IDE (محيط پيشرفت ادغام شده) در حال رشد است. Cloud IDE ها امكان همكاري در زمان واقعي بين تيم هاي توسعه دهنده را فراهم مي كنند تا در يك محيط توسعه يكپارچه كار كنند كه ناسازگاري ها را به حداقل مي رساند و بهره وري را افزايش مي دهد. IDE cloudها كه از طريق مرورگرهاي وب قابل دسترسي هستند ، از هر نوع دستگاه مدرن قابل استفاده اند.
code-server يك كدMicrosoft Visual Studio است كه روي يك سرور از راه دور اجرا مي شود و مستقيماً از طريق مرورگر شما قابل دسترسي است. كد ويژوال استوديو يك ويرايشگر كد مدرن داراي پشتيباني يكپارچه از Git ، اشكال زدايي كد ، تكميل خودكار هوشمند و ويژگي هاي قابل تنظيم و قابل توسعه است. اين بدان معني است كه مي توانيد از دستگاه هاي مختلفي كه سيستم عامل هاي متفاوت را اجرا مي كنند استفاده كنيد و هميشه يك محيط توسعه مداوم داشته باشيد.
در اين آموزش ، پلت فرم code-server cloud IDE را بر روي دستگاه CentOS 7 خود تنظيم كرده و آن را در دامنه خود قرار مي دهيد ، كه با استفاده از گواهينامه هاي TLS Let’s Encrypt  رايگان ايمن شده اند. در پايان ، كد مايكروسافت ويژوال استوديو را روي سرور CentOS 7 خود ، در دامنه خود در دسترس خواهيد داشت كه با يك رمز عبور محافظت مي شود.
پيش نيازها
سروري كه CentOS 7 را با حداقل 2 گيگابايت رم ، دسترسي به روت و يك حساب سودو و غير روت اجرا مي كند. با دنبال كردن اين راهنماي اوليه تنظيم سرور مي توانيد اين تنظيمات را انجام دهيد.
Nginx روي سرور شما نصب شده است. براي راهنمايي در مورد نحوه انجام اين كار ، به نحوه نصب Nginx در CentOS 7 مراجعه كنيد.
هر دو پرونده DNS زير براي سرور شما تنظيم شده اند. براي جزئيات بيشتر در مورد چگونگي اضافه كردن آنها مي توانيد اين مقدمه را در vpsgol DNS دنبال كنيد.
يك ركورد A با your-domain كه به آدرس IP عمومي سرور شما اشاره ميكند.
يك ركورد A با www.your-domain كه به آدرس IP عمومي سرور شما اشاره ميكند.
يك نام دامنه كاملاً ثبت شده براي كد سرور هاست، كه به سرور شما اشاره ميكند. در اين آموزش از code-server.your-domain استفاده مي شود. مي توانيد يك نام دامنه به اسم Namecheap خريداري كنيد ، يكي از آنها را به صورت رايگان در Freenom دريافت كنيد ، يا از ثبت دامنه مورد نظر خود استفاده كنيد.
مرحله 1 – نصب كد سرور
در اين بخش كد سرور را روي سرور خود تنظيم مي كنيد. اين كار مستلزم دانلود آخرين نسخه و ايجاد سرويس systemd است كه كد سرور را هميشه در پس زمينه اجرا مي كند. همچنين رويكرد مجدد را براي سرويس تعيين خواهيد كرد ، به اين ترتيب كه كد سرور پس از خرابي يا راه اندازي مجدد احتمالي در دسترس باشد.

همه داده هاي مربوط به كد سرور را در پوشه اي به نام ~ / code-server ذخيره مي كنيد. با اجراي دستور زير آن را ايجاد كنيد:
mkdir ~/code-server
حركت به سمت آن:
cd ~/code-server
شما بايد به صفحه انتشار نسخه هاي Github از كد سرور برويد و آخرين ساخت لينوكس را انتخاب كنيد (نام فايل شامل “linux” است). در زمان نوشتن ، آخرين نسخه 2.1692 بود. با اجراي دستور زير آن را با استفاده از curl دانلود كنيد:
curl -LO https://github.com/cdr/code-server/releases/download/2.1692-vsc1.39.2/code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz
سپس با اجراي اين دستور آرشيو را باز كنيد:
tar -xzvf code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz
پوشه اي دقيقاً به عنوان فايل اصلي كه دانلود كرده ايد ، تهيه مي شود كه شامل كد سرور قابل اجرا است. به آن فايل برويد:
cd code-server2.1692-vsc1.39.2-linux-x86_64
سرور كد قابل اجرا را در / usr / local / bin كپي كنيد تا با اجراي دستور زير بتوانيد به سيستم گسترده اي از آن دسترسي داشته باشيد:
sudo cp code-server /usr/local/bin
سپس، يك پوشه براي سرور كد ايجاد كنيد ، كه در آن داده هاي كاربر را ذخيره مي كند:
sudo mkdir /var/lib/code-server
اكنون كه كد سرور را دانلود كرده ايد و آن را به صورت گسترده در دسترس سيستم قرار داده ايد، يك سرويس سيستمي ايجاد خواهيد كرد تا كد سرور را هميشه در پس زمينه اجرا كند.
پيكربندي سرويس را در فايلي به نام code-server.service ، در ديركتوري / usr / lib / systemd / system ذخيره خواهيد كرد، جايي كه systemd خدمات خود را ذخيره مي كند. با استفاده از ويرايشگر vi آن را ايجاد كنيد:
sudo vi /usr/lib/systemd/system/code-server.service
خطوط زير را اضافه كنيد:
/usr/lib/systemd/system/code-server.service
[Unit]
Description=code-server
After=nginx.service

[Service]
Type=simple
Environment=PASSWORD=your_password
ExecStart=/usr/local/bin/code-server –host 127.0.0.1 –user-data-dir /var/lib/code-server –auth password
Restart=always

[Install]
WantedBy=multi-user.target

در اينجا ابتدا شرح خدمات را مشخص مي كنيد. سپس ، اعلام مي كنيد كه سرويس nginx بايد قبل از اين شروع شود. بعد از بخش [Unit] نوع سرويس را تعريف مي كنيد (simple بدان معني است كه فرايند بايد به سادگي اجرا شود) و فرماني را كه اجرا مي شود ارائه مي دهيد.
شما همچنين مشخص مي كنيد كه كد سرور جهاني قابل اجرا بايد با چند آرگومان خاص براي كد سرور آغاز شود. –host 127.0.0.1 آن را به localhost متصل مي كند ، بنابراين فقط از داخل سرور شما قابل دسترسي است. –user-data-dir / var / lib / code-server دايركتوري داده هاي كاربر خود را تنظيم مي كند ، و –auth password مشخص مي كند كه بايد بازديد كنندگان را با يك رمزعبور، مشخص شده در متغير محيط PASSWORD اعلام شده در خط بالاي آن ، تأييد كند.
به ياد داشته باشيد كه your_password را با رمز عبور دلخواه خود جايگزين كنيد. براي ذخيره و بستن فايل تايپ كنيد: wq و سپس ENTER را بزنيد.
خط بعدي به systemd مي گويد تا كد سرور را در تمام رويدادهاي ناقص (براي مثال وقتي كه دچار crash ميشود يا فرآيند نابود ميشود) مجددا راه اندازي كند. بخش [Install] به systemd سفارش مي دهد تا در صورت امكان ورود به سرور خود ، اين سرويس را شروع كند.
با اجراي دستور زير سرويس كد سرور را شروع كنيد:
sudo systemctl start code-server
با مشاهده وضعيت آن بررسي كنيد كه درست شروع شده است:
sudo systemctl status code-server
خروجي شبيه به زير را خواهيد ديد:
Output
code-server.service – code-server
Loaded: loaded (/usr/lib/systemd/system/code-server.service; disabled; vendor preset: disabled)
Active: active (running) since Thu 2019-12-19 19:24:42 UTC; 5s ago
Main PID: 1668 (code-server)
CGroup: /system.slice/code-server.service
├─1668 /usr/local/bin/code-server –host 127.0.0.1 –user-data-dir /var/lib/code-server –auth password
└─1679 /usr/local/bin/code-server –host 127.0.0.1 –user-data-dir /var/lib/code-server –auth password

Dec 19 19:24:42 code-server-centos systemd[1]: Started code-server.
Dec 19 19:24:44 code-server-centos code-server[1668]: info Server listening on http://127.0.0.1:8080
Dec 19 19:24:44 code-server-centos code-server[1668]: info – Using custom password for authentication
Dec 19 19:24:44 code-server-centos code-server[1668]: info – Not serving HTTPS

براي شروع خودكار كد سرور پس از راه اندازي مجدد سرور ، سرويس آن را با اجراي دستور زير فعال كنيد:
sudo systemctl enable code-server
در اين مرحله ، شما كد سرور را دانلود كرده و آن را در سطح جهاني در دسترس قرار داده ايد. سپس ، شما يك سرويس systemd براي آن ايجاد و آن را فعال كرده ايد ، بنابراين كد سرور از هر بوت سرور شروع مي شود. در مرحله بعد ، با پيكربندي Nginx ، آن را در دامنه خود قرار مي دهيد تا به عنوان يك پروكسي معكوس بين بازديد كننده و كد سرور خدمت كند.
مرحله 2 – قرار گرفتن كد سرور در معرض دامنه شما
در اين بخش، Nginx را به عنوان يك پروكسي معكوس براي سرور كد پيكربندي مي كنيد.
همانطور كه در مرحله پيش نياز Nginx آموخته ايد، فايل هاي پيكربندي سايت آن در زير /etc/nginx/conf.d ذخيره مي شوند و با شروع Nginx بطور خودكار دانلود مي شوند.
شما پيكربندي را براي در معرض قرار گرفتن كد سرور در دامنه خود در فايلي به نامcode-server.conf ، تحت عنوان /etc/nginx/conf.d ذخيره مي كنيد. با استفاده از ويرايشگر خود شروع به كار كنيد:
sudo vi /etc/nginx/conf.d/code-server.conf
خطوط زير را اضافه كنيد:
/etc/nginx/conf.d/code-server.conf
server {
listen 80;
listen [::]:80;

server_name code-server.your-domain;

location / {
غير مجاز مي باشد_pass http://localhost:8080/;
غير مجاز مي باشد_set_header Upgrade $http_upgrade;
غير مجاز مي باشد_set_header Connection upgrade;
غير مجاز مي باشد_set_header Accept-Encoding gzip;
}
}

code-server.your-domain خود را با دامنه مورد نظر خود جايگزين كنيد، سپس فايل را ذخيره كنيد و ببنديد.
در اين فايل ، شما تعريف مي كنيد كه Nginx بايد به پورت HTTP 80 گوش دهد. سپس ، يك server_nameرا تعيين مي كنيد كه به Nginx مي گويد كه كدام دامنه درخواست ها را بپذيرد و از اين تنظيمات خاص استفاده كند.
در بلوك بعدي ، براي مكان ريشه (/) ، شما تعيين مي كنيد كه درخواست ها بايد به كد سروري كه در localhost:8080 در حال اجرا است ، در رفت و برگشت باشد: سه خط بعدي (كه با غير مجاز مي باشد_set_header شروع ميشوند) به Nginx دستور مي دهند برخي از سرصفحات HTTP را كه براي عملكرد صحيح WebSockets مورد نياز هستند، كه از سرورهاي كد استفاده گسترده اي دارند، حمل كند.
براي آزمايش اعتبار پيكربندي ، دستور زير را اجرا كنيد:
sudo nginx -t
خروجي زير را مشاهده خواهيد كرد:
utput
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

براي اينكه پيكربندي عملي شود ، بايد Nginx را مجدداً راه اندازي كنيد:
sudo systemctl restart nginx
CentOS 7 مجهز به SELinux است ، با يك آيين نامه سختگيرانه ، كه به طور پيش فرض اجازه اتصال Nginx به سوكت هاي محلي TCP را نمي دهد. Nginx براي خدمت به عنوان يك پروكسي معكوس براي كد سرور ، بايد در حال اجرا باشد. دستور زير را اجرا كنيد تا قاعده را به صورت دائمي آرام كنيد:
sudo setsebool httpd_can_network_connect 1 -P
سپس در مرورگر خود به سمت دامنه مورد استفاده براي كد سرور مجازي برويد. اعلان ورود به سيستم كد را مشاهده خواهيد كرد.
كد سرور از شما رمز عبور مي خواهد. چيزي كه در مرحله قبل تنظيم كرديد را وارد كنيد و Enter IDE را بزنيد. اكنون كد سرور را وارد كرده و فوراً GUI ويرايشگر آن را مشاهده مي كنيد.
اكنون نصب كد سرور مجازي شما در دامنه شما قابل دسترسي است. در مرحله بعدي ، با استفاده از يك گواهي نامه Let’s Encrypt TLS رايگان ، آن را ايمن خواهيد كرد.
مرحله 3 – دامنه خود را ايمن كنيد
در اين بخش دامنه خود را با استفاده از گواهي Let’s Encrypt TLS ، كه با استفاده از Certbot ارائه مي دهيد ، تضمين مي كنيد.
براي نصب آخرين نسخه Certbot و افزونه Nginx آن، دستور زير را اجرا كنيد:
sudo yum install certbot python2-certbot-nginx
براي درخواست گواهي نامه براي دامنه خود ، دستور زير را اجرا كنيد:
sudo certbot –nginx -d code-server.your-domain
در اين دستور ، شما certbot را براي درخواست گواهينامه براي دامنه خود اجرا مي كنيد – نام دامنه را با پارامتر -d مي گذرانيد. فلگ –nginx به آن مي گويد براي پشتيباني از HTTPS ، پيكربندي سايت Nginx را به طور خودكار تغيير دهد. به ياد داشته باشيد كه دامنه code-server.your خود را با نام دامنه خود جايگزين كنيد.
اگر اولين بار است كه Certbot را اجرا مي كنيد ، از شما خواسته مي شود كه يك آدرس ايميل را براي اخطارهاي فوري و قبول شرايط خدمات EFF وارد كنيد. سپس Certbot از Let’s Encrypt براي گواهي دامنه شما درخواست مي كند. سپس از شما سؤال مي كند كه آيا مايليد همه ترافيك HTTP را به HTTPS هدايت كنيد:
Output
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
1: No redirect – Make no further changes to the webserver configuration.
2: Redirect – Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you’re confident your site works on HTTPS. You can undo this
change by editing your web server’s configuration.
– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel):

توصيه مي شود براي به حداكثر رساندن امنيت، گزينه دوم را انتخاب كنيد. پس از وارد كردن انتخاب خود ، ENTER را فشار دهيد.
خروجي مشابه اين خواهد بود:
Output
IMPORTANT NOTES:
– Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/code-server.your-domain/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/code-server.your-domain/privkey.pem
Your cert will expire on … To obtain a new or tweaked
version of this certificate in the future, simply run certbot again
with the “certonly” option. To non-interactively renew *all* of
your certificates, run “certbot renew”
– Your account credentials have been saved in your Certbot
configuration directory at /etc/letsencrypt. You should make a
secure backup of this folder now. This configuration directory will
also contain certificates and private keys obtained by Certbot so
making regular backups of this folder is ideal.
– If you like Certbot, please consider supporting our work by:

Donating to ISRG / Let’s Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le

اين بدان معني است كه Certbot با موفقيت توليد گواهينامه TLS را انجام داده و آنها را در پيكربندي Nginx براي دامنه شما اعمال كرده است. اكنون مي توانيد دامنه كد سرور مجازي خود را در مرورگر خود مجدد لود كنيد و يك padlock در سمت چپ آدرس سايت مشاهده كنيد، به اين معني كه اتصال شما به درستي ايمن شده است.
اكنون كاري كرديد كه Certbot به طور خودكار گواهينامه ها را قبل از اين كه منقضي شوند تمديد كند. براي اجراي بررسي روزانه، از cron ، يك سرويس سيستم استاندارد براي انجام كارهاي دوره اي استفاده خواهيد كرد. شما با باز كردن و ويرايش فايلي به نام crontab ، corn را هدايت مي كنيد:
sudo crontab -e
اين دستور crontab پيش فرض را كه در حال حاضر يك فايل متني خالي است ، باز مي كند. خط زير را اضافه كنيد ، سپس آن را ذخيره كرده و ببنديد:
crontab
. . .
15 3 * * * /usr/bin/certbot renew –quiet

دستور renew براي Certbot تمام گواهينامه هاي نصب شده روي سيستم را بررسي ميكند و مواردي را كه در كمتر از سي روز به پايان مي رسند به روز مي كند. –quiet به Certbot مي گويد كه اطلاعات را بيرون نكشيد يا منتظر ورود كاربر نباشيد.
cron اكنون اين دستور را روزانه اجرا مي كند. تمام گواهينامه هاي نصب شده هنگامي كه سي روز يا كمتر از اين كه منقضي شود به طور خودكار تجديد و لود مي شوند.
اكنون كه كد سرور مجازي را از طريق يك پروكسي معكوس Nginx در دامنه خود داريد ، آماده بررسي واسط كاربري سرور كد هستيد.
مرحله 4 – استفاده از رابط كد-سرور مجازي
در اين بخش از برخي از ويژگي هاي رابط كد-سرور مجازي استفاده خواهيد كرد. از آنجا كه كد-سرور مجازي كد ويژوال استوديو در حال اجرا در cloud است ، همان رابط مشابه نسخه دسكتاپ مستقل دارد.
در سمت چپ IDE ، يك رديف عمودي از شش دكمه وجود دارد كه بيشترين ويژگي هاي مورد استفاده را در يك صفحه جانبي كه با عنوان Activity Bar شناخته مي شود باز مي كند.
اين نوار قابل تنظيم است بنابراين مي توانيد اين نماها را به ترتيب ديگري جابجا كنيد يا آنها را از نوار حذف كنيد. به طور پيش فرض ، اولين دكمه منوي كلي را به صورت كشويي باز مي كند ، در حالي كه نماي دوم پنل اكسپلورر را باز مي كند كه پيمايش درخت مانند از ساختار پروژه را فراهم مي كند. مي توانيد پوشه ها و فايل هاي خود را در اينجا مديريت كنيد – ايجاد ، حذف ، جابجايي و تغيير نام را در صورت لزوم انجام دهيد. نماي بعدي امكان دسترسي به جستجو و جايگزيني عملكرد را فراهم مي كند.
بعد از اين ، به ترتيب پيش فرض ، نماي شما از سيستم هاي كنترل منبع مانند Git است. كد ويژوال استوديو همچنين از ارائه دهندگان ديگر كنترل منبع پشتيباني مي كند و مي توانيد در اين مطالب دستورالعمل هاي بيشتري را براي جريان كار كنترل منبع با ويرايشگر پيدا كنيد.
گزينه اشكال زدايي در نوار فعاليت ، كليه اقدامات متداول را براي اشكال زدايي در پنل ارائه مي دهد. كد ويژوال استوديو با پشتيباني داخلي براي اشكال زدايي زمان اجرا Node.js و هر زباني كه به Javascript تبديل شود همراه است. براي ساير زبانها مي توانيد پسوندهايي را براي اشكالزدگي مورد نياز نصب كنيد. مي توانيد پيكربندي هاي اشكال زدايي را در پرونده start.json ذخيره كنيد.
نماي نهايي در نوار فعاليت، منويي را براي دسترسي به افزونه هاي موجود در Marketplace فراهم مي كند.
قسمت اصلي GUI ويرايشگر شماست كه مي توانيد با استفاده از زبانه ها براي ويرايش كد خود جدا كنيد. مي توانيد نماي ويرايش خود را به يك سيستم شبكه يا به فايل هاي جانبي تغيير دهيد.
پس از ايجاد فايل جديد از طريق منوي File ، يك فايل خالي در يك سربرگ جديد باز مي شود و پس از ذخيره سازي ، نام فايل در صفحه جانبي Explorer قابل مشاهده خواهد بود. ايجاد پوشه ها را مي توان با كليك راست بر روي نوار كناري Explorer و كليك بر روي New Folder انجام داد. مي توانيد پوشه اي را با كليك روي نام آن و همچنين كشيدن و رها كردن فايل ها و پوشه ها به قسمتهاي بالاي ليست ترتيبي گسترش دهيد تا آنها را به يك مكان جديد منتقل كنيد.
مي توانيد با زدن CTRL + SHIFT + `، يا با كليك كردن بر روي ترمينال در منوي كشويي بالا، و انتخاب گزينه New Terminal، به ترمينال دسترسي پيدا كنيد. ترمينال در يك پنل پايين تر باز خواهد شد و فهرست كار آن روي فضاي كاري پروژه تنظيم مي شود ، كه شامل فايل ها و پوشه هاي نمايش داده شده در پانل سمت Explorer است.
شما يك نماي كلي سطح بالا از رابط كد سرور مجازي را جستجو كرده ايد و برخي از متداول ترين ويژگي ها را مرور كرده ايد.
نتيجه
اكنون شما داراي كد سرور مجازي، يك cloud IDE همه كاره هستيد كه بر روي سرور CentOS 7 شما نصب شده است ، و در دامنه شما قرار گرفته و با استفاده از گواهي نامه هاي رمزگذاري ايمن شده است. هم اكنون مي توانيد بر روي پروژه ها بصورت جداگانه و همچنين در يك مجموعه همكاري تيمي كار كنيد. اجراي cloud IDE منابع موجود در دستگاه محلي شما را آزاد مي كند و به شما امكان مي دهد منابع را در صورت لزوم مقياس بندي كنيد. براي اطلاعات بيشتر ، به ويژگي هاي اضافي و دستورالعمل هاي دقيق در مورد ساير مؤلفه هاي كد سرور ، به مطالب ويژوال استوديو مراجعه كنيد.
اگر مايل هستيد كد سرور مجازي را روي خوشه vpsgol Kubernetes خود اجرا كنيد ، آموزش ما در مورد چگونگي راه اندازي بستر رمزگذاري كد سرويس دهنده Cloud IDE در vpsgol Kubernetes را بررسي كنيد.

مقدمه
DNSControl ابزاري زيرساختي به عنوان كد است كه به شما امكان مي دهد بخش هاي DNS خود را با استفاده از اصول استاندارد توسعه نرم افزار از جمله كنترل نسخه ، آزمايش و استقرار خودكار گسترش دهيد و مديريت كنيد. DNSControl توسط Stack Exchange ايجاد شده و در Go نوشته شده است.
استفاده از DNSControl بسياري از مشكلات مديريت دستي DNS را از بين مي برد ، زيرا فايل هاي بخش در يك قالب قابل برنامه ريزي ذخيره مي شوند. اين امر به شما امكان مي دهد بخش هاي مختلفي را به طور همزمان به چندين ارائه دهنده DNS گسترش دهيد ، خطاهاي دستوري را شناسايي كرده و پيكربندي DNS خود را به صورت خودكار انجام دهيد و خطاي انساني را كاهش دهيد. يكي ديگر از كاربردهاي متداول DNSControl انتقال سريع DNS شما به يك ارائه دهنده ديگر است. به عنوان مثال ، در صورت حمله DDoS يا قطع سيستم.
در اين آموزش ، DNSControl را نصب و پيكربندي خواهيد كرد ، يك پيكربندي اساسي DNS ايجاد كرده و شروع به گسترش سوابق DNS به يك ارائه دهنده زنده مي كنيد. به عنوان بخشي از اين آموزش ، ما از vpsgol به عنوان ارائه دهنده DNS نمونه استفاده خواهيم كرد. اگر مي خواهيد از ارائه دهنده ديگري استفاده كنيد ، تنظيمات بسيار مشابه است. پس از اتمام ، مي توانيد پيكربندي DNS خود را در يك محيط امن آفلاين مديريت و آزمايش كنيد و سپس بطور خودكار آن را به مرحله توليد منتقل كنيد.
پيش نيازها
قبل از شروع اين راهنما به موارد زير نياز خواهيد داشت:
⦁ يك سرور مجازي Debian 10 كه با دنبال كردن ستاپ سرور مجازي اوليه با Debian 10 راه اندازي شده ، از جمله كاربر sudo غير ريشه و فايروال فعال براي اينكه پورت هاي غير ضروري را مسدود كند. your-server-ipv4-address به آدرس IP سرور مجازي اشاره دارد، جايي كه وب سايت يا دامنه خود را ميزباني مي كنيد. your-server-ipv6-address به آدرس IPv6 سرور مجازي اشاره دارد جايي كه ميزبان وب سايت يا دامنه خود هستيد.
⦁ نام دامنه كاملاً ثبت شده با DNS كه توسط يك ارائه دهنده پشتيباني شده ميزباني مي شود. در اين آموزش از your_domain و vpsgol به عنوان ارائه دهنده خدمات استفاده مي شود.
⦁ يك كليد API vpsgol (نشانه دسترسي شخصي) با مجوزهاي خواندن و نوشتن. براي ايجاد يك چنين كليدي، به نحوه ايجاد نشانه دسترسي شخصي مراجعه كنيد.
پس از آماده شدن ، به عنوان كاربر غير ريشه وارد سرور مجازي خود شويد.
مرحله 1 – نصب DNSControl
DNSControl در Go نوشته شده است ، بنابراين اين مرحله را با نصب Go روي سرور مجازي خود و تنظيم GOPATH خود شروع خواهيد كرد.
Go در منابع پيش فرض نرم افزار Debian موجود است و نصب آن با استفاده از ابزارهاي مديريت بسته معمولي امكان پذير است.
همچنين بايد Git را نصب كنيد ، زيرا اين امر به شما اجازه مي دهد تا نرم افزار DNSControl را از منبع آن در GitHub دانلود و نصب كنيد.
با به روز كردن ايندكس پكيج محلي شروع كنيد تا تغييرات جديد بالادست را منعكس كنيد:
$ sudo apt update
سپس پكيج هاي golang-go و git را نصب كنيد:
$sudo apt install golang-go git
پس از تأييد نصب ، apt دو برنامه Go و Git و همچنين كليه موارد مورد نياز خود را دانلود و نصب خواهد كرد.
در مرحله بعد ، متغيرهاي مورد نياز محيط مسير را براي Go پيكربندي خواهيد كرد. اگر دوست داريد در اين باره اطلاعات بيشتري كسب كنيد ، مي توانيد اين آموزش آشنايي با GOPATH را بخوانيد. با ويرايش فايل ~/.profile شروع كنيد:
⦁ $ nano ~/.profile
خطوط زير را به انتهاي فايل خود اضافه كنيد:
~/.profile
…
export GOPATH=”$HOME/go”
export PATH=”$PATH:$GOPATH/bin”

پس از افزودن اين خطوط به پايين فايل ، آن را ذخيره كرده و ببنديد. سپس پروفايل خود را با ورود به سيستم و برگشت مجدد يا سورس دهي فايل دوباره بارگيري كنيد:
⦁ $ source ~/.profile
اكنون Go را نصب كرده و پيكربندي كرده ايد ، مي توانيد DNSControl را نصب كنيد.
از دستور go get مي توان براي گرفتن كپي از كد ، كامپايل آن به صورت خودكار و نصب آن در فهرست Go استفاده كرد:
⦁ $ go get github.com/StackExchange/dnscontrol
پس از اتمام اين كار ، مي توانيد نسخه نصب شده را بررسي كنيد تا مطمئن شويد كه همه چيز كار مي كند:

⦁ $ dnscontrol version
خروجي شما شبيه به زير خواهد بود:
Output
dnscontrol 2.9-dev

اگر يك خطاي dnscontrol: command not found مشاهده كرديد ، راه اندازي مسير Go خود را دو بار بررسي كنيد.
اكنون كه DNSControl را نصب كرده ايد ، مي توانيد يك دايركتوري پيكربندي ايجاد كرده و DNSControl را به ارائه دهنده DNS خود متصل كنيد تا اجازه دهيد تغييراتي در فايل هاي DNS شما ايجاد كند.
مرحله 2 – پيكربندي DNSControl
در اين مرحله ، دايركتوري هاي تنظيمات لازم را براي DNSControl ايجاد خواهيد كرد و آن را به ارائه دهنده DNS خود وصل كنيد تا بتواند شروع به ايجاد تغييرات زنده در سوابق DNS كند.
ابتدا يك دايركتوري جديد ايجاد كنيد كه در آن بتوانيد پيكربندي DNSControl خود را ذخيره كنيد و سپس به داخل آن برويد:
⦁ $ mkdir ~/dnscontrol
⦁ $ cd ~/dnscontrol
توجه: اين آموزش در مورد تنظيم اوليه DNSControl است. اما براي استفاده توليدي، توصيه مي شود پيكربندي DNSControl را در سيستم كنترل نسخه (VCS) مانند Git ذخيره كنيد. از مزاياي اين امر مي توان به كنترل كامل نسخه ، ادغام با CI / CD براي آزمايش ، گسترش چرخشي يكپارچه و غيره اشاره كرد.
اگر قصد داريد از DNSControl براي نوشتن فايل هاي بخش BIND استفاده كنيد ، بايد ديركتوري zones  را نيز ايجاد كنيد:
⦁ $ mkdir ~/dnscontrol/zones
فايل هاي بخش BIND يك روش استاندارد و خام براي ذخيره بخش ها/ فايل هاي DNS با فرمت متني ساده است. آنها در ابتدا براي نرم افزار سرور مجازي BIND DNS مورد استفاده قرار گرفتند ، اما اكنون به عنوان روش استاندارد براي ذخيره سازي بخش هاي DNS مورد استفاده قرار ميگيرند. اگر مي خواهيد آنها را به يك سرور مجازي DNS سفارشي يا ميزبان سرخود يا براي اهداف حسابرسي وارد كنيد ، فايل هاي بخش BIND توليد شده توسط DNSControl مفيد هستند.
با اين حال ، اگر فقط مي خواهيد از DNSControl براي ايجاد تغييرات DNS به يك ارائه دهنده مديريت شده استفاده كنيد ، ديركتوري zones  مورد نياز نخواهد بود.
در مرحله بعد ، بايد فايل creds.json را پيكربندي كنيد ، اين همان چيزي است كه به DNSControl اجازه مي دهد تا به ارائه دهنده DNS خود صدقيت دهيد و تغييراتي ايجاد كند. فرمت creds.json بسته به ارائه دهنده DNS مورد استفاده شما كمي متفاوت است. لطفاً به ليست ارائه دهندگان خدمات در اسناد رسمي DNSControl مراجعه كنيد تا پيكربندي ارائه دهنده خود را پيدا كنيد.

فايل creds.json را در ديركتوري ~ / dnscontrol ايجاد كنيد:

⦁ $ cd ~/dnscontrol
⦁ $ nano creds.json
پيكربندي نمونه creds.json را براي ارائه دهنده DNS خود به فايل اضافه كنيد. اگر از vpsgol به عنوان ارائه دهنده DNS خود استفاده مي كنيد ، مي توانيد موارد زير را استفاده كنيد:
~/dnscontrol/creds.json
{
“vpsgol“: {
“token”: “your-vpsgol-oauth-token”
}
}

اين فايل به DNSControl ميگويد كه شما ميخواهيد به كدام ارائه دهندگان DNS متصل شود.
بايد براي ارائه دهنده DNS نوعي تأييد اعتبار را ارائه دهيد. اين معمولاً يك كليد API يا نشان OAuth است ، اما برخي از ارائه دهندگان به اطلاعات اضافي نياز دارند ، همانطور كه در ليست ارائه دهندگان خدمات در اسناد DNSControl ثبت شده است.
هشدار: اين نشانه به حساب ارائه دهنده DNS شما دسترسي مي يابد ، بنابراين بايد آن را مانند رمز عبور خود محافظت كنيد. همچنين ، اطمينان حاصل كنيد كه اگر از سيستم كنترل نسخه استفاده مي كنيد ، فايلي كه حاوي نشانه است ، حذف نشده باشد (مثلاً با استفاده از .gitignore) يا به طريقي رمزگذاري شود.
اگر از vpsgol به عنوان ارائه دهنده DNS خود استفاده مي كنيد ، مي توانيد از علائم مورد نياز OAuth در تنظيمات حساب vpsgol خود كه به عنوان بخشي از پيش نيازها توليد كرده ايد استفاده كنيد.
اگر چندين ارائه دهنده DNS مختلف داريد- مثلاً براي نام هاي دامنه متعدد ، يا بخش هاي DNS تفويض شده- مي توانيد همه اينها را در همان فايل creds.json تعريف كنيد.
شما دايركتوري هاي پيكربندي اوليه DNSControl را تنظيم كرده ايد و creds.json را پيكربندي كرده ايد تا به DNSControl اجازه دهيد تا ارائه دهنده DNS خود را تأييد كنيد و تغييرات ايجاد نماييد. در مرحله بعدي پيكربندي را براي بخش هاي DNS خود ايجاد خواهيد كرد.
مرحله 3 – ايجاد يك فايل پيكربندي DNS
در اين مرحله ، يك فايل پيكربندي اوليه DNS ايجاد خواهيد كرد ، كه شامل سوابق DNS براي نام دامنه يا بخش DNS تفويض شده شما خواهد بود.

dnsconfig.js فايل اصلي پيكربندي DNS براي DNSControl است. در اين فايل ، بخش هاي DNS و سوابق مربوط به آنها با استفاده ازJavaScript تعريف شده است. كه به DSL يا Domain Specific Language معروف است. صفحه JavaScript DSL در مطالب DNSControl جزئيات بيشتري را ارائه مي دهد.
براي شروع ، فايل پيكربندي DNS را در فهرست ~ / dnscontrol ايجاد كنيد:
⦁ $ cd ~/dnscontrol
⦁ $ nano dnsconfig.js
سپس پيكربندي نمونه زير را به فايل اضافه كنيد:
~ / dnscontrol / dnsconfig. ~/dnscontrol/dnsconfig.js
// Providers:

var REG_NONE = NewRegistrar(‘none’, ‘NONE’);
var DNS_vpsgol = NewDnsProvider(‘vpsgol‘, ‘vpsgol‘);

// Domains:

D(‘your_domain’, REG_NONE, DnsProvider(DNS_vpsgol),
A(‘@’, ‘your-server-ipv4-address’)
);

اين فايل نمونه نام دامنه يا بخش DNS را در يك ارائه دهنده خاص تعريف مي كند ، كه در اين حالت your_domain به ميزباني vpsgol است. يك سابقه A نيز براي ريشه بخش (@)تعريف شده است ، كه به آدرس IPv4 سرور مجازي كه ميزبان دامنه / وب سايت شما هستند اشاره دارد.
سه كاركرد اصلي وجود دارد كه يك فايل پيكربندي اساسي DNSControl را تشكيل مي دهند:
⦁ NewRegistrar(name, type, metadata) : ثبت دامنه را براي نام دامنه شما تعيين مي كنيد. DNSControl مي تواند از اين روش براي ايجاد تغييرات مورد نياز مانند تغيير نام سرورهاي معتبر استفاده كند. اگر فقط مي خواهيد از DNSControl براي مديريت بخش هاي DNS خود استفاده كنيد ، اين حالت معمولاً به عنوان NONE باقي مي ماند.
⦁ NewDnsProvider(name, type, metadata) : ارائه دهنده خدمات DNS را براي نام دامنه يا بخش واگذار شده تعريف مي كند. اينجاست كه DNSControl تغييرات DNS را ايجاد مي كند.
⦁ D(name, registrar, modifiers) : يك نام دامنه يا بخش DNS تفويض شده براي مديريت DNSControl ، و همچنين سوابق DNS موجود در بخش تعريف ميكند.
شما بايد با استفاده از ليست ارائه دهندگان خدمات در مطالب DNSControl ، NewRegistrar () ، NewDnsProvider () و D () را پيكربندي كنيد.
اگر از vpsgol به عنوان ارائه دهنده DNS خود استفاده مي كنيد ، و فقط نياز داريد بتوانيد DNS را تغيير دهيد (به جاي نام سرورهاي معتبر) ، نمونه موجود در بلوك كد قبلي نيز صحيح است.
پس از تكميل ، فايل را ذخيره كنيد و ببنديد.
در اين مرحله ، يك فايل پيكربندي DNS را براي DNSControl ، با ارائه دهندگان مربوطه تعريف شده، تنظيم مي كنيد. در مرحله بعد ، فايل را با برخي از سوابق مفيد DNS پر مي كنيد.
مرحله 4 – پر كردن فايل پيكربندي DNS
در مرحله بعد ، مي توانيد با استفاده از نحو DNSControl ، فايل پيكربندي DNS را با سوابق مفيد DNS براي وب سايت يا خدمات خود پر كنيد.
بر خلاف فايل هاي بخش BIND قديمي ، كه در آن فايل هاي DNS با فرمت خام و خط به خط نوشته مي شوند ، سوابق DNS درون DNSControl به عنوان يك پارامتر تابع (اصلاح كننده دامنه) به عملكرد D () تعريف مي شوند ، كه مختصراً در مرحله 3 نشان داده شده است.
يك اصلاح كننده دامنه براي هر يك از انواع استاندارد ركورد DNS ، از جمله A ، AAAA ، MX ، TXT ، NS ، CAA و غيره وجود دارد. ليست كاملي از انواع ركورد موجود در بخش Domain Modifiers مطالب DNSControl موجود است.
اصلاح كننده هاي مربوط به سوابق جداگانه نيز در دسترس هستند (اصلاح كننده هاي سابقه). در حال حاضر اينها در درجه اول براي تنظيم TTL (زمان زندگي) سوابق فردي استفاده مي شود. ليست كاملي از اصلاح كننده هاي ضبط موجود در بخش Record Modifiers در اسناد DNSControl موجود است. اصلاح كننده هاي ثبت اختياري هستند و در اكثر موارد استفاده اصلي مي توان آنها را كنار گذاشت.
دستور تنظيم سوابق DNS براي هر نوع ركورد كمي متفاوت است. در زير چند نمونه از رايج ترين انواع ركورد وجود دارد:
ركوردهاي A :
هدف: براي اشاره به آدرس IPv4.
دستور: A(‘name’, ‘address’, optional record modifiers)
مثال: A(‘@’, ‘your-server-ipv4-address’, TTL(30))
ركوردهاي AAAA :
هدف: براي اشاره به آدرس IPv6.
دستور: AAAA(‘name’, ‘address’, optional record modifiers)
مثال: AAAA(‘@’, ‘your-server-ipv6-address’) (اصلاح كننده ركورد از كار افتاده ، بنابراين TTL پيش فرض استفاده خواهد شد)
ركوردهاي CNAME :

هدف: براي تبديل دامنه / زير دامنه شما به عنوان يك نام مستعار ديگر.
دستور: CNAME(‘name’, ‘target’, optional record modifiers)
مثال: CNAME(‘subdomain1’, ‘example.org.’) (توجه داشته باشيد كه اگر نقطه هايي در مقدار وجود داشته باشد بايد يك دنباله . درج شود)
ركوردهاي MX :
هدف: براي هدايت ايميل به سرورها و آدرس هاي خاص.
دستور: MX(‘name’, ‘priority’, ‘target’, optional record modifiers)
مثال: MX(‘@’, 10, ‘mail.example.net’) توجه داشته باشيد كه اگر نقطه هايي در مقدار وجود داشته باشد بايد يك دنباله . درج شود)
ركوردهاي TXT :
هدف: براي افزودن متن ساده دلخواه ، اغلب براي تنظيمات بدون نوع ركورد خاص خود استفاده مي شوند.
دستور: TXT(‘name’, ‘content’, optional record modifiers)
مثال: TXT(‘@’, ‘This is a TXT record.’)
ركوردهاي CAA :
هدف: محدود كردن و گزارش در مورد مجوزها(CA) كه مي توانند گواهينامه TLS را براي دامنه / زير دامنه شما صادر كنند.
دستور: CAA(‘name’, ‘tag’, ‘value’, optional record modifiers)
مثال: CAA(‘@’, ‘issue’, ‘letsencrypt.org’)
براي شروع اضافه كردن ركوردهاي DNS براي دامنه يا بخش DNS تفويض شده ، پيكربندي DNS خود را ويرايش كنيد:
⦁ $ nano dnsconfig.js
در مرحله بعد ، مي توانيد پر كردن پارامترهاي مربوط به عملكرد D () موجود را با استفاده از دستور گفته شده در ليست قبلي ، و همچنين بخش Domain Modifiers از مطالب DNSControl شروع كنيد. كاما (،) بايد بين هر ركوردي استفاده شود.
براي ارجاع ، بلوك كد در اينجا حاوي يك پيكربندي كامل نمونه براي يك تنظيم DNS ساده اوليه است:
~/dnscontrol/dnsconfig.js
…

D(‘your_domain’, REG_NONE, DnsProvider(DNS_vpsgol),
A(‘@’, ‘your-server-ipv4-address’),
A(‘www’, ‘your-server-ipv4-address’),
A(‘mail’, ‘your-server-ipv4-address’),
AAAA(‘@’, ‘your-server-ipv6-address’),
AAAA(‘www’, ‘your-server-ipv6-address’),
AAAA(‘mail’, ‘your-server-ipv6-address’),
MX(‘@’, 10, ‘mail.your_domain.’),
TXT(‘@’, ‘v=spf1 -all’),
TXT(‘_dmarc’, ‘v=DMARC1; p=reject; rua=mailto:abuse@your_domain; aspf=s; adkim=s;’)
);

پس از تكميل تنظيمات اوليه DNS ، فايل را ذخيره كنيد و ببنديد.
در اين مرحله فايل پيكربندي اوليه DNS را تنظيم مي كنيد كه شامل سوابق DNS شماست. در مرحله بعد ، پيكربندي را تست كرده و آن را مستقر مي كنيد.
مرحله 5 – تست و استفاده از پيكربندي DNS
در اين مرحله ، شما يك بررسي دستور محلي را بر روي پيكربندي DNS خود اجرا كرده و سپس تغييرات را در سرور مجازي / ارائه دهنده زنده DNS مستقر مي كنيد.
در مرحله اول ، به فهرست dnscontrol خود برويد:
⦁ $ cd ~/dnscontrol
در مرحله بعدي ، از عملكرد پيش نمايش DNSControl استفاده كنيد تا دستور فايل خود را بررسي كنيد و تغييرات را ايجاد كنيد (بدون اينكه آنها را در واقع ايجاد كنيد)
⦁ $ dnscontrol preview
اگر دستور فايل پيكربندي DNS شما صحيح باشد ، DNSControl مروري بر تغييراتي كه ايجاد مي كند ، ارائه مي دهد. كه بايد شبيه زير باشد:
Output
******************** Domain: your_domain
—– Getting nameservers from: vpsgol
—– DNS Provider: vpsgol…8 corrections
#1: CREATE A your_domain your-server-ipv4-address ttl=300
#2: CREATE A www.your_domain your-server-ipv4-address ttl=300
#3: CREATE A mail.your_domain your-server-ipv4-address ttl=300
#4: CREATE AAAA your_domain your-server-ipv6-address ttl=300
#5: CREATE TXT _dmarc.your_domain “v=DMARC1; p=reject; rua=mailto:abuse@your_domain; aspf=s; adkim=s;” ttl=300
#6: CREATE AAAA www.your_domain your-server-ipv6-address ttl=300
#7: CREATE AAAA mail.your_domain your-server-ipv6-address ttl=300
#8: CREATE MX your_domain 10 mail.your_domain. ttl=300
—– Registrar: none…0 corrections
Done. 8 corrections.

اگر هشدار خطايي را در خروجي خود مشاهده مي كنيد ، DNSControl جزئياتي راجع به اينكه چه خطايي و در كجاي فايل شما قرار دارد ارائه ميدهد.
هشدار: دستور بعدي تغييراتي را در سوابق DNS شما و احتمالاً ساير تنظيمات ايجاد مي كند. لطفاً اطمينان حاصل كنيد كه براي اين كار آمادگي داريد ، از جمله گرفتن نسخه پشتيبان از پيكربندي DNS موجود خود ، و همچنين اطمينان از داشتن ابزارهايي براي بازگرداندن در صورت لزوم.
سرانجام ، مي توانيد تغييرات را در ارائه دهنده DNS زنده خود ايجاد كنيد:
⦁ $ dnscontrol push
خروجي مشابه با زير را مشاهده خواهيد كرد:
Output
******************** Domain: your_domain
—– Getting nameservers from: vpsgol
—– DNS Provider: vpsgol…8 corrections
#1: CREATE TXT _dmarc.your_domain “v=DMARC1; p=reject; rua=mailto:abuse@your_domain; aspf=s; adkim=s;” ttl=300
SUCCESS!
#2: CREATE A your_domain your-server-ipv4-address ttl=300
SUCCESS!
#3: CREATE AAAA your_domain your-server-ipv6-address ttl=300
SUCCESS!
#4: CREATE AAAA www.your_domain your-server-ipv6-address ttl=300
SUCCESS!
#5: CREATE AAAA mail.your_domain your-server-ipv6-address ttl=300
SUCCESS!
#6: CREATE A www.your_domain your-server-ipv4-address ttl=300
SUCCESS!
#7: CREATE A mail.your_domain your-server-ipv4-address ttl=300
SUCCESS!
#8: CREATE MX your_domain 10 mail.your_domain. ttl=300
SUCCESS!
—– Registrar: none…0 corrections
Done. 8 corrections.

حال اگر تنظيمات DNS مربوط به دامنه خود را در كنترل پنل vpsgol بررسي كنيد ، تغييرات را مشاهده خواهيد كرد.

همچنين مي توانيد با اجراي يك جستجوي DNS براي بخش دامنه / تفويض شده خود با استفاده از Dig ، ايجاد ركورد را بررسي كنيد.
اگر dig را نصب نكرديد ، بايد بسته dnsutils را نصب كنيد:
⦁ $ sudo apt install dnsutils
پس از نصب dig ، مي توانيد از آن براي جستجوي DNS براي دامنه خود استفاده كنيد. خواهيد ديد كه سوابق به همين ترتيب به روز شده اند:
⦁ $ dig +short your_domain
خروجي را مشاهده خواهيد كرد كه آدرس IP و سابقه DNS مربوطه را از بخش شما كه با استفاده از DNSControl مستقر شده است نشان ميدهد. سوابق DNS مي تواند مدتي طول بكشد تا گسترش يابد ، بنابراين ممكن است لازم باشد كه صبر كنيد و اين دستور را دوباره اجرا كنيد.
در اين مرحله آخر ، شما يك بررسي نحو محلي فايل پيكربندي DNS را اجرا كرديد ، سپس آن را به ارائه دهنده زنده DNS خود مستقر كرديد و آزمايش كرديد كه تغييرات با موفقيت انجام شده اند.
نتيجه
در اين مقاله شما DNSControl را تنظيم كرده و پيكربندي DNS را به يك ارائه دهنده زنده مستقر كرده ايد. اكنون مي توانيد تغييرات پيكربندي DNS خود را در يك محيط امن و آفلاين قبل از گسترش آنها ، مديريت و آزمايش كنيد.
اگر مي خواهيد اين موضوع را بيشتر بررسي كنيد ، DNSControl به گونه اي طراحي شده است كه در خط CI / CD شما ادغام شود ، به شما اين امكان را مي دهد تا تست هاي عميق را انجام دهيد و كنترل بيشتري بر روي به كارگيري براي توليد داشته باشيد. همچنين مي توانيد DNSControl را در فرآيندهاي ساخت و استقرار زيرساخت خود ادغام كنيد ، كه به شما امكان مي دهد سرورها را مستقر كرده و آنها را به طور كامل به DNS اضافه كنيد.
اگر مي خواهيد با DNSControl بيشتر پيش برويد ، مقالات vpsgol را در ادامه ببينيد كه مراحل بعدي جالب ديگري را براي كمك به ادغام DNSControl در مديريت تغيير و گردش كار شما در زمينه استقرار زيرساخت ها ارائه مي دهد:
⦁ مقدمه اي براي ادغام مداوم ، تحويل و استقرار
⦁ مقايسه ابزارهاي CI / CD: Jenkins ، GitLab CI ، Buildbot ،Drone و Concourse
⦁ شروع به كار با مديريت پيكربندي