জবাবদিহি মোতায়েনের সময় nginx.conf বৈধ করুন

11

আমার বেশ কয়েকটি সাইট চলমান একটি একক উত্তর-বিধানযুক্ত সার্ভার রয়েছে।

আমার উত্তরীয় কাজগুলি দেখতে মোটামুটি দেখতে:

- name: site nginx config
  template: src="nginx-site.conf.j2" dest=/etc/nginx/conf.d/{{item.name}}.conf
            owner=root group=root mode=0444
  with_items: sites
  notify: restart nginx

- name: nginx conf
  template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf 
            owner=root group=root mode=0444
  notify: restart nginx

আমি validateকল nginx -tকরতে এবং আমার নতুন কনফিগারগুলি সিনট্যাক্টিকভাবে বৈধ কিনা তা নিশ্চিত করার জন্য আমি উত্তরযোগ্য টেম্পলেট মডিউলটির প্যারামিটারটি ব্যবহার করতে চাই । এটি মূল nginx.conf এর জন্য কাজ করে:

  template: src=nginx.conf.j2 dest=/etc/nginx/nginx.conf 
            owner=root group=root mode=0444
            validate="/usr/sbin/nginx -c %s -t"

তবে এটি সাইট-নির্দিষ্ট কনফিগার ফাইলগুলিতে পরিবর্তনগুলি গ্রহণ করবে বলে মনে হয় না। validateসাইট-নির্দিষ্ট টেম্পলেটগুলি রাখলে কাজ হয় না, কারণ তাদের httpবৈধ হওয়ার জন্য কোনও নির্দেশে মোড়ানো দরকার ।

এই সাইট-নির্দিষ্ট ফাইলগুলির বৈধতা পরীক্ষা করতে আমি কী করতে পারি?

nginx ansible

— ইরিন কল
সূত্র

9

আপনি সেখানে কিছু কৌশল এবং বৈধতাযুক্ত ফাইলের মতো করতে পারেন ( https://gist.github.com/psd/5042334 থেকে ধার করা ধারণা ): validate: bash -c 'nginx -t -c /dev/stdin <<< "events {worker_connections 1;} http { include %s; }"'

— Hubbitus
সূত্র

এই আসলে কাজ করে, upvote!

— 13dimitar

4

validateআপনার এনজিএনএক্স প্রধান কনফিগারেশন ফাইলের অন্তর্ভুক্ত একটি ফাইলকে সরাসরি কল করতে কোনও অর্থ হয় না কারণ একটি নির্দিষ্ট কনফিগারেশন ফাইলের নির্দেশনার বৈধতা আপনার বাকী কনফিগারেশন ফাইলের উপর নির্ভর করতে পারে (উদাহরণস্বরূপ আপনার দুটি কনফিগারেশন ফাইল রয়েছে যা একই সার্ভার ব্লক ঘোষণা করে) ইত্যাদি)।

আপনি nginx -tযখনই কোনও এনগিনেক্সের কনফিগারেশন পরিবর্তনকে বৈধতা দিতে চান তখন আপনাকে অবশ্যই সর্বদা মুখ্য কনফিগারেশন ফাইলটিতে কল করতে হবে এবং এর একটি উপ-অংশ নয়।

— জাভিয়ের লুকাস
সূত্র

1

ঠিক আছে. সুতরাং আমি অনুমান করি যে আমাকে এক ছোঁয়ায় বৈধতার জন্য সমস্ত কিছু বান্ডিল করতে জবাবদিহি করতে হবে?

— ইরিন কল করুন

@ এরিনকল আপনার প্লেবুকটি আন্তঃক্রিয়াযুক্ত হয়ে থাকলেও আদর্শভাবে আপনার এনগিনেক্স কনফিগারেশনটি সম্পূর্ণ বৈধ থাকতে হবে।

— মাইকেল হ্যাম্পটন

3

আমি অন্যান্য উত্তরের উদ্বেগকে বিবেচনায় নিয়ে স্বীকৃত উত্তরের অনুরূপ একটি পন্থা ব্যবহার করেছি।

আমি এই উদ্দেশ্যটি এই উদ্দেশ্যে তৈরি করেছি।

ধারণাটি হ'ল পুরো /etc/nginxডিরেক্টরিটি একটি অস্থায়ী ডিরেক্টরিতে অনুলিপি করা , %sপ্যারামিটার থেকে একটি ফাইল পরিবর্তন করা এবং সমস্যার জন্য প্রধান এনজিনেক্স কনফিগারেশন পরীক্ষা করা। আপনি যদি ধরে নেন যে প্রাথমিকভাবে এনগিনেক্স কনফিগারেশনটি বৈধ এবং সমস্ত কাজ যা নিগিনেক্স কনফিগারকে সংশোধন করে তা যাচাই করতে ব্যবহার করে, তবে আমার ধারণা কোনও সমস্যা হবে না।

ওয়ান লাইনার হিসাবে এটি দেখতে এই রকম হবে:

validate: bash -c 'NGINX_CONF_DIR=`mktemp -d`; cp -rTp /etc/nginx/ "$NGINX_CONF_DIR" && cp -Tp %s "$NGINX_CONF_DIR"/sites-enabled/new-site.conf && nginx -t -c "$NGINX_CONF_DIR"/nginx.conf'

— jadkik94
সূত্র

1

গ্রহণযোগ্য উত্তরের পরিবর্তে আমার এই সমাধানটি প্রয়োজন কারণ আমার এনজিন্স কনফেস্টে ফাস্টসিজি_প্যারামগুলি অন্তর্ভুক্ত ছিল।

— হ্যাঁ_আইটি এর_আমি

3

এখানে আরও সোজা উপায় যা কমপক্ষে উত্তরযোগ্য 2.5 এর সাথে কাজ করে:

- name: Verify Nginx config
  become: yes
  command: nginx -t
  changed_when: false

এটি এর সমতুল্য চালায় sudo nginx -tএবং এর আউটপুট পরীক্ষা করে। যদি এনজিনেক্স কনফিগারেশনে কোনও ত্রুটি থাকে তবে এটি শূন্য নয় এবং উত্তরীয় কার্যটি ত্রুটি ঘটবে ( changed_when)।

আপনি যদি ব্যবহারকারী হিসাবে এনগিনেক্স ইনস্টল করেন তবে কেবল এটি সরিয়ে ফেলুন become, যদিও আমি মনে করি এটি এখনও এটি দিয়ে কাজ করবে।

— জুহা আনটিনেন
সূত্র

1

এটি একটি খারাপ উদাহরণ, যখন templateমডিউলটি এবং উত্তরটিতে বৈধতা বিকল্পটি ব্যবহার করার সময় আপনার কনফিগারেশনের বৈধতার জন্য গ্যারান্টি থাকে তবে আপনি যদি টেম্পলেটটি স্থাপন করেন এবং তারপরে ম্যানুয়াল চেক এবং ব্যর্থ হন তবে আপনার এখনও সমস্যা রয়েছে যা একটি অবৈধ টেমপ্লেট মোতায়েন করা হয়েছিল এবং এটি পুনরায় ফেরানোর দরকার নেই।

— রবিন