الـ Console وAWS CLI v2

لديك حساب آمن وهوية مدير. النقر في أرجاء الـ console يكفي لنظرة أولى، لكن القائمين على Lantern يريدون شيئًا يستطيعون تكراره، ولصقه في دليل تشغيل (runbook)، ومراجعته في pull request. كل زر في الـ console يستدعي API من AWS، وAWS CLI v2 يتيح لك استدعاء الـ APIs نفسها من الطرفية.

الـ console أم الـ CLI؟

استخدم الـ console للاستكشاف، وقراءة لوحات المعلومات، والمهام التي تنفّذها مرة واحدة وتريد رؤيتها بصريًا، مثل النظرة الأولى على فاتورة. واستخدم الـ CLI لكل ما ستفعله مرتين، ولكل ما يجب أن يراجعه زميل، ولكل ما تريد التراجع عنه بدقّة. الأمر في سكربت توثيق؛ أما سلسلة النقرات فمجرد ذكرى.

إذا لم تستطع تثبيت أي شيء، فإن AWS CloudShell يمنحك طرفية في المتصفّح داخل الـ console، فيها الـ CLI مثبّتًا ومسجّل الدخول بهوية الـ console الخاصة بك.

التثبيت والتحقّق من الإصدار

ثبّت من الحزمة الرسمية لنظامك. على Linux x86-64:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws --version

على macOS تنشر AWS مُثبِّتًا بصيغة .pkg، وعلى Windows بصيغة .msi. أيًّا كان ما تستخدمه، يجب أن يطبع aws --version العبارة aws-cli/2. متبوعة برقم الإصدار. تحتاج إلى الإصدار 2.32.0 أو أحدث لأمر تسجيل الدخول أدناه؛ وإذا كان لديك تثبيت قديم من الإصدار 1، فأزله أولًا، لأن الإصدارين يتصرّفان بشكل مختلف.

سجّل الدخول دون مفاتيح وصول

كانت الطريقة القديمة هي aws configure، حيث تلصق معرّف مفتاح وصول طويل الأمد وسرّه في ~/.aws/credentials. هذه المفاتيح لا تنتهي صلاحيتها أبدًا، وتتسرّب عبر النسخ الاحتياطية ولقطات الشاشة والـ commits في Git. أما اليوم فتسجّل الدخول بهوية الـ console الخاصة بك بدلًا من ذلك:

aws login --profile lantern-admin

يسألك الـ CLI عن Region افتراضية في المرة الأولى (أدخل الـ Region الخاصة بـ Lantern)، ثم يفتح متصفّحك، وبعد أن تسجّل الدخول بكلمة المرور والـ MFA، يخزّن بيانات اعتماد قصيرة الأمد تتجدّد تلقائيًا لمدة تصل إلى 12 ساعة. يُضاف إلى ملف ~/.aws/config لديك profile كهذا، ولاحظ أنه لا يحتوي على أي سرّ:

[profile lantern-admin]
login_session = arn:aws:iam::111122223333:user/amara
region = eu-west-1

يحتاج مستخدم IAM إلى صلاحية لاستخدام هذه الطريقة؛ والسياسة AdministratorAccess من الدرس السابق تتضمّنها بالفعل، أما للمستخدمين ذوي الصلاحيات الأضيق فتوفّر AWS السياسة المُدارة SignInLocalDevelopmentAccess. والفرق التي تستخدم IAM Identity Center تسجّل الدخول بدلًا من ذلك عبر aws configure sso وaws sso login، وستتعرّف إليهما في القسم الثاني. وعندما تنتهي، يحذف aws logout --profile lantern-admin بيانات الاعتماد المخزّنة.

من أنا؟

أكثر الأوامر فائدةً في AWS هو أيضًا أكثرها مللًا:

aws sts get-caller-identity --profile lantern-admin

{
  "UserId": "AIDAEXAMPLEUSERID1234",
  "Account": "111122223333",
  "Arn": "arn:aws:iam::111122223333:user/amara"
}

لا يحتاج إلى أي صلاحيات ولا يغيّر شيئًا، لذا تستطيع حتى هوية جديدة تمامًا بلا سياسات مرفقة أن تشغّله. إذا فشل، فالمشكلة في بيانات اعتمادك لا في صلاحياتك: جلسة منتهية، أو اسم profile خاطئ، أو لا اتصال بالشبكة. إنه يخبرك بـ الحساب والهوية اللذين سيستخدمهما كل أمر لاحق. شغّله قبل أي شيء مدمّر، وفي السكربتات تحقّق من أن Account هو الحساب الذي تتوقّعه قبل المتابعة.

تشكيل المخرجات

الاستجابات بصيغة JSON افتراضيًا، وكثيرًا ما تكون طويلة. يساعدك خياران عامّان:

• --output يختار التنسيق: json أو text أو table أو yaml.
• --query يرشّح الاستجابة بتعبير JMESPath على جهازك قبل الطباعة.

aws s3api list-buckets --profile lantern-admin \
  --query "Buckets[].Name" --output text

يطبع هذا أسماء الـ buckets فقط، مفصولة بمسافات جدولة، وجاهزة لحلقة تكرار في الـ shell. ولأن --query يُنفَّذ محليًا، فهو لا يقلّل ما تعيده AWS ولا تكلفة الاستدعاء؛ بل يقلّل فقط ما عليك قراءته.

بهذا يكتمل القسم الأول: تعرف أين تشغّل AWS مواردك، ومن يؤمّن ماذا، وكيف تدير الحساب بأمان. يدخل القسم الثاني إلى أعماق IAM، النظام الذي يقرّر هل يُسمح بكل استدعاء من تلك الاستدعاءات الأخرى. (get-caller-identity هو الاستثناء الوحيد: يعمل حتى لو منعته سياسة.)