How to copy file from master to minions on salt-stack?

Solution 1:

file.recurse is for copying the content of a directory if I’m correct. Here, what you have to do to copy just one file would be to use file.managed.

For instance reusing your example, this should be working:

copy_my_files:
  file.managed:
    - name: /etc/nginx/nginx.conf
    - source: salt://nginx.conf
    - makedirs: True

Note that the nginx.conf file you want to copy has to be located in /srv/salt on the salt master. Thats the default place were the salt:// is pointing (unless you modified your configuration)

If you want to copy multiple file using the file.recurse it’s also quite easy

deploy linter configuration:
  file.recurse:
    - name: "/usr/local/linter"
    - source: salt://devtools/files/linter
    - makedirs: True
    - replace: True
    - clean: True

Solution 2:

The source can be any file on the master. It does not need to be within the salt fileserver.

salt-cp '*' SOURCE [SOURCE2 SOURCE3 ...] DEST

How can I exclude all subdirectories but include files of a directory in rsync?

Try this command:

rsync -a -f"- */" -f"+ *" /home/user/ destination/

man rsync

-f, --filter=RULE           add a file-filtering RULE

The rule to include all files* and exclude the dirs */

Another approach to use the regular copy cp

cp /home/usr/* /destination

you can get rid of the errors about dirs using redirection

cp /home/usr/* /destination 2>/dev/null

This will only copies the files inside your home without the directories

If you want to exclude all *.sh from all subdirectories:
-f”- */*.sh”

python: uninstall python 2.7 install via source

To completely remove python you can execute:

rm -f /usr/local/bin/python2.7
rm -f /usr/local/bin/pip2.7
rm -f /usr/local/bin/pydoc
rm -rf /usr/local/bin/include/python2.7
rm -f /usr/local/lib/libpython2.7.a
rm -rf /usr/local/lib/python2.7

You might also have to do

rm -f /usr/local/share/man/python2.7.1
rm -rf /usr/local/lib/pkgconfig
rm -f /usr/local/bin/idle
rm -f /usr/local/bin/easy_install-2.7

iptables: delete specific rule

You can list the existing iptables rule along with their line number with:

iptables -L –line-numbers

The output will be as follows:

Chain INPUT (policy ACCEPT)
num target prot opt source destination
1 KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
2 KUBE-FIREWALL all -- anywhere anywhere
3 ACCEPT udp -- anywhere anywhere udp dpt:domain
4 ACCEPT tcp -- anywhere anywhere tcp dpt:domain
5 ACCEPT udp -- anywhere anywhere udp dpt:bootps
6 ACCEPT tcp -- anywhere anywhere tcp dpt:bootps


Then you can delete the rule with the line-number  3 with:
iptables -D INPUT 3

Ansible cheat sheet

Configuration file

intro_configuration.html

First one found from of

  • Contents of $ANSIBLE_CONFIG
  • ./ansible.cfg
  • ~/.ansible.cfg
  • /etc/ansible/ansible.cfg

Configuration settings can be overridden by environment variables – see constants.py in the source tree for names.

Patterns

intro_patterns.html

Used on the ansible command line, or in playbooks.

  • all (or *)
  • hostname: foo.example.com
  • groupname: webservers
  • or: webservers:dbserver
  • exclude: webserver:!phoenix
  • intersection: webservers:&staging

Operators can be chained: webservers:dbservers:&staging:!phoenix

Patterns can include variable substitutions: {{foo}}, wildcards: *.example.com or 192.168.1.*, and regular expressions: ~(web|db).*\.example\.com

Inventory files

intro_inventory.htmlintro_dynamic_inventory.html

‘INI-file’ structure, blocks define groups. Hosts allowed in more than one group. Non-standard SSH port can follow hostname separated by ‘:’ (but see also ansible_ssh_port below).

Hostname ranges: www[01:50].example.comdb-[a:f].example.com

Per-host variables: foo.example.com foo=bar baz=wibble

  • [foo:children]: new group foo containing all members if included groups
  • [foo:vars]: variable definitions for all members of group foo

Inventory file defaults to /etc/ansible/hosts. Veritable with -i or in the configuration file. The ‘file’ can also be a dynamic inventory script. If a directory, all contained files are processed.

Variable files:

intro_inventory.html

YAML; given inventory file at ./hosts:

  • ./group_vars/foo: variable definitions for all members of group foo
  • ./host_vars/foo.example.com: variable definitions for foo.example.com

group_vars and host_vars directories can also exist in the playbook directory. If both paths exist, variables in the playbook directory will be loaded second.

Behavioral inventory parameters:

intro_inventory.html

  • ansible_ssh_host
  • ansible_ssh_port
  • ansible_ssh_user
  • ansible_ssh_pass
  • ansible_sudo_pass
  • ansible_connection
  • ansible_ssh_private_key_file
  • ansible_python_interpreter
  • ansible_*_interpreter

Playbooks

playbooks_intro.htmlplaybooks_roles.html

Playbooks are a YAML list of one or more plays. Most (all?) keys are optional. Lines can be broken on space with continuation lines indented.

Playbooks consist of a list of one or more ‘plays’ and/or inclusions:

---
- include: playbook.yml
- <play>
- ...

Plays

playbooks_intro.htmlplaybooks_roles.htmlplaybooks_variables.htmlplaybooks_conditionals.html,playbooks_acceleration.htmlplaybooks_delegation.htmlplaybooks_prompts.htmlplaybooks_tags.html Forum postingForum postinb

Plays consist of play metadata and a sequence of task and handler definitions, and roles.

- hosts: webservers
  remote_user: root
  sudo: yes
  sudo_user: postgress
  su: yes
  su_user: exim
  gather_facts: no
  accelerate: no
  accelerate_port: 5099
  any_errors_fatal: yes
  max_fail_percentage: 30
  connection: local
  serial: 5
  vars:
    http_port: 80
  vars_files:
    - "vars.yml"
    - [ "try-first.yml", "try-second-.yml" ]
  vars_prompt:
    - name: "my_password2"
      prompt: "Enter password2"
      default: "secret"
      private: yes
      encrypt: "md5_crypt"
      confirm: yes
      salt: 1234
      salt_size: 8
  tags: 
    - stuff
    - nonsence
  pre_tasks:
    - <task>
    - ...
  roles:
    - common
    - { role: common, port: 5000, when: "bar == 'Baz'", tags :[one, two] }
    - { role: common, when: month == 'Jan' }
    - ...
  tasks:
    - include: tasks.yaml
    - include: tasks.yaml foo=bar baz=wibble
    - include: tasks.yaml
      vars:
        foo: aaa 
        baz:
          - z
          - y
    - { include: tasks.yaml, foo: zzz, baz: [a,b]}
    - include: tasks.yaml
      when: day == 'Thursday'
    - <task>
    - ...
  post_tasks:
    - <task>
    - ...
  handlers:
    - include: handlers.yml
    - <task>
    - ...

Using encrypt with vars_prompt requires that Passlib is installed.

In addition the source code implies the availability of the following which don’t seem to be mentioned in the documentation: nameuser (deprecated), portaccelerate_ipv6role_names, and vault_password.

Task definitions

playbooks_intro.htmlplaybooks_roles.htmlplaybooks_async.htmlplaybooks_checkmode.htmlplaybooks_delegation.html,playbooks_environment.htmlplaybooks_error_handling.htmlplaybooks_tags.html ansible-1-5-released Forum postingAnsible examples

Each task definition is a list of items, normally including at least a name and a module invocation:

- name: task
  remote_user: apache
  sudo: yes
  sudo_user: postgress
  sudo_pass: wibble
  su: yes
  su_user: exim
  ignore_errors: True
  delegate_to: 127.0.0.1
  async: 45
  poll: 5
  always_run: no
  run_once: false
  meta: flush_handlers
  no_log: true
  environment: <hash>
  environment:
    var1: val1
    var2: val2
  tags: 
    - stuff
    - nonsence
  <module>: src=template.j2 dest=/etc/foo.conf
  action: <module>, src=template.j2 dest=/etc/foo.conf
  action: <module>
  args:
      src=template.j2
      dest=/etc/foo.conf
  local_action: <module> /usr/bin/take_out_of_pool {{ inventory_hostname }}
  when: ansible_os_family == "Debian"
  register: result
  failed_when: "'FAILED' in result.stderr"
  changed_when: result.rc != 2
  notify:
    - restart apache

delegate_to: 127.0.0.1 is implied by local_action:

The forms <module>: <args>action: <module> <args>, and local_action: <module> <args> are mutually-exclusive.

Additional keys when_*untilretries and delay are documented below under ‘Loops’.

In addition the source code implies the availability of the following which don’t seem to be mentioned in the documentation:first_available_file (deprecated), transportconnectionany_errors_fatal.

Roles

playbooks_roles.html

Directory structure:

playbook.yml
roles/
   common/
     tasks/
       main.yml
     handlers/
       main.yml
     vars/
       main.yml
     meta/
       main.yml
     defaults/
       main.yml
     files/
     templates/
     library/

Modules

modules.htmmodules_by_category.html

List all installed modules with

ansible-doc --list

Document a particular module with

ansible-doc <module>

Show playbook snippet for specified module

ansible-doc -i <module>

Variables

playbooks_roles.htmlplaybooks_variables.html

Names: letters, digits, underscores; starting with a letter.

Substitution examples:

  • {{ var }}
  • {{ var["key1"]["key2"]}}
  • {{ var.key1.key2 }}
  • {{ list[0] }}

YAML requires an item starting with a variable substitution to be quoted.

Sources:

  • Highest priority:
    • --extra-vars on the command line
  • General:
    • vars component of a playbook
    • From files referenced by vars_file in a playbook
    • From included files (incl. roles)
    • Parameters passed to includes
    • register: in tasks
  • Lower priority:
    • Inventory (set on host or group)
  • Lower priority:
    • Facts (see below)
    • Any /etc/ansible/facts.d/filename.fact on managed machines (sets variables with `ansible_local.filename. prefix)
  • Lowest priority
    • Role defaults (from defaults/main.yml)

Built-in:

  • hostvars (e.g. hostvars[other.example.com][...])
  • group_names (groups containing current host)
  • groups (all groups and hosts in the inventory)
  • inventory_hostname (current host as in inventory)
  • inventory_hostname_short (first component of inventory_hostname)
  • play_hosts (hostnames in scope for current play)
  • inventory_dir (location of the inventory)
  • inventoty_file (name of the inventory)

Facts:

Run ansible hostname -m setup, but in particular:

  • ansible_distribution
  • ansible_distribution_release
  • ansible_distribution_version
  • ansible_fqdn
  • ansible_hostname
  • ansible_os_family
  • ansible_pkg_mgr
  • ansible_default_ipv4.address
  • ansible_default_ipv6.address

Content of ‘registered’ variables:

playbooks_conditionals.htmlplaybooks_loops.html

Depends on module. Typically includes:

  • .rc
  • .stdout
  • .stdout_lines
  • .changed
  • .msg (following failure)
  • .results (when used in a loop)

See also failedchanged, etc filters.

When used in a loop the result element is a list containing all responses from the module.

Additionally available in templates:

  • ansible_managed: string containing the information below
  • template_host: node name of the templateâ��s machine
  • template_uid: the owner
  • template_path: absolute path of the template
  • template_fullpath: the absolute path of the template
  • template_run_date: the date that the template was rendered

Filters

playbooks_variables.html

  • {{ var | to_nice_json }}
  • {{ var | to_json }}
  • {{ var | from_json }}
  • {{ var | to_nice_yml }}
  • {{ var | to_yml }}
  • {{ var | from_yml }}
  • {{ result | failed }}
  • {{ result | changed }}
  • {{ result | success }}
  • {{ result | skipped }}
  • {{ var | manditory }}
  • {{ var | default(5) }}
  • {{ list1 | unique }}
  • {{ list1 | union(list2) }}
  • {{ list1 | intersect(list2) }}
  • {{ list1 | difference(list2) }}
  • {{ list1 | symmetric_difference(list2) }}
  • {{ ver1 | version_compare(ver2, operator='>=', strict=True }}
  • {{ list | random }}
  • {{ number | random }}
  • {{ number | random(start=1, step=10) }}
  • {{ list | join(" ") }}
  • {{ path | basename }}
  • {{ path | dirname }}
  • {{ path | expanduser }}
  • {{ path | realpath }}
  • {{ var | b64decode }}
  • {{ var | b64encode }}
  • {{ filename | md5 }}
  • {{ var | bool }}
  • {{ var | int }}
  • {{ var | quote }}
  • {{ var | md5 }}
  • {{ var | fileglob }}
  • {{ var | match }}
  • {{ var | search }}
  • {{ var | regex }}
  • {{ var | regexp_replace('from', 'to' )}}

See also default jinja2 filters. In YAML, values starting { must be quoted.

Lookups

playbooks_lookups.html

Lookups are evaluated on the control machine.

  • {{ lookup('file', '/etc/foo.txt') }}
  • {{ lookup('password', '/tmp/passwordfile length=20 chars=ascii_letters,digits') }}
  • {{ lookup('env','HOME') }}
  • {{ lookup('pipe','date') }}
  • {{ lookup('redis_kv', 'redis://localhost:6379,somekey') }}
  • {{ lookup('dnstxt', 'example.com') }}
  • {{ lookup('template', './some_template.j2') }}

Lookups can be assigned to variables and will be evaluated each time the variable is used.

Lookup plugins also support loop iteration (see below).

Conditions

playbooks_conditionals.html

when: <condition>, where condition is:

  • var == "Vaue"var >= 5, etc.
  • var, where var coreces to boolean (yes, true, True, TRUE)
  • var is definedvar is not defined
  • <condition1> and <condition2> (also or?)

Combined with with_items, the when statement is processed for each item.

when can also be applied to includes and roles. Conditional Imports and variable substitution in file and template names can avoid the need for explicit conditionals.

Loops

playbooks_loops.html

In addition the source code implies the availability of the following which don’t seem to be mentioned in the documentation: csvfileetcdinventory_hostname.

Standard:

- user: name={{ item }} state=present groups=wheel
  with_items:
    - testuser1
    - testuser2
   
- name: add several users
  user: name={{ item.name }} state=present groups={{ item.groups }}
  with_items:
    - { name: 'testuser1', groups: 'wheel' }
    - { name: 'testuser2', groups: 'root' }

  with_items: somelist

Nested:

- mysql_user: name={{ item[0] }} priv={{ item[1] }}.*:ALL                
                           append_privs=yes password=foo
  with_nested:
    - [ 'alice', 'bob', 'eve' ]
    - [ 'clientdb', 'employeedb', 'providerdb' ]

Over hashes:

Given

---
users:
  alice:
    name: Alice Appleworth
    telephone: 123-456-7890
  bob:
    name: Bob Bananarama
    telephone: 987-654-3210
    
tasks:
  - name: Print phone records
    debug: msg="User {{ item.key }} is {{ item.value.name }} 
                     ({{ item.value.telephone }})"
    with_dict: users

Fileglob:

- copy: src={{ item }} dest=/etc/fooapp/ owner=root mode=600
  with_fileglob:
    - /playbooks/files/fooapp/*

In a role, relative paths resolve relative to the roles/<rolename>/files directory.

With content of file:

(see example for authorized_key module)

- authorized_key: user=deploy key="{{ item }}"
  with_file:
    - public_keys/doe-jane
    - public_keys/doe-john

See also the file lookup when the content of a file is needed.

Parallel sets of data:

Given

---
alpha: [ 'a', 'b', 'c', 'd' ]
numbers:  [ 1, 2, 3, 4 ]

- debug: msg="{{ item.0 }} and {{ item.1 }}"
  with_together:
    - alpha
    - numbers

Subelements:

Given

---
users:
  - name: alice
    authorized:
      - /tmp/alice/onekey.pub
      - /tmp/alice/twokey.pub
  - name: bob
    authorized:
      - /tmp/bob/id_rsa.pub

- authorized_key: "user={{ item.0.name }} 
                   key='{{ lookup('file', item.1) }}'"
  with_subelements:
     - users
     - authorized

Integer sequence:

Decimal, hexadecimal (0x3f8) or octal (0600)

- user: name={{ item }} state=present groups=evens
  with_sequence: start=0 end=32 format=testuser%02x
      
  with_sequence: start=4 end=16 stride=2
      
  with_sequence: count=4

Random choice:

- debug: msg={{ item }}
  with_random_choice:
     - "go through the door"
     - "drink from the goblet"
     - "press the red button"
     - "do nothing"

Do-Until:

- action: shell /usr/bin/foo
  register: result
  until: result.stdout.find("all systems go") != -1
  retries: 5
  delay: 10

Results of a local program:

- name: Example of looping over a command result
  shell: /usr/bin/frobnicate {{ item }}
  with_lines: /usr/bin/frobnications_per_host 
                       --param {{ inventory_hostname }}

To loop over the results of a remote program, use register: result and then with_items: result.stdout_lines in a subsequent task.

Indexed list:

- name: indexed loop demo
  debug: msg="at array position {{ item.0 }} there is 
                                     a value {{ item.1 }}"
  with_indexed_items: some_list

Flattened list:

---
# file: roles/foo/vars/main.yml
packages_base:
  - [ 'foo-package', 'bar-package' ]
packages_apps:
  - [ ['one-package', 'two-package' ]]
  - [ ['red-package'], ['blue-package']]
  
- name: flattened loop demo
  yum: name={{ item }} state=installed
  with_flattened:
    - packages_base
    - packages_apps      

First found:

- name: template a file
  template: src={{ item }} dest=/etc/myapp/foo.conf
  with_first_found:
    - files:
        - {{ ansible_distribution }}.conf
        - default.conf
      paths:
         - search_location_one/somedir/
         - /opt/other_location/somedir/

Tags

Both plays and tasks support a tags: attribute.

- template: src=templates/src.j2 dest=/etc/foo.conf
  tags:
    - configuration

Tags can be applied to roles and includes (effectively tagging all included tasks)

roles:
    - { role: webserver, port: 5000, tags: [ 'web', 'foo' ] }

- include: foo.yml tags=web,foo

To select by tag:

ansible-playbook example.yml --tags "configuration,packages"
ansible-playbook example.yml --skip-tags "notification"

Command lines

ansible

Usage: ansible <host-pattern> [options]

Options:
  -a MODULE_ARGS, --args=MODULE_ARGS
                        module arguments
  -k, --ask-pass        ask for SSH password
  --ask-su-pass         ask for su password
  -K, --ask-sudo-pass   ask for sudo password
  --ask-vault-pass      ask for vault password
  -B SECONDS, --background=SECONDS
                        run asynchronously, failing after X seconds
                        (default=N/A)
  -C, --check           don't make any changes; instead, try to predict some
                        of the changes that may occur
  -c CONNECTION, --connection=CONNECTION
                        connection type to use (default=smart)
  -f FORKS, --forks=FORKS
                        specify number of parallel processes to use
                        (default=5)
  -h, --help            show this help message and exit
  -i INVENTORY, --inventory-file=INVENTORY
                        specify inventory host file
                        (default=/etc/ansible/hosts)
  -l SUBSET, --limit=SUBSET
                        further limit selected hosts to an additional pattern
  --list-hosts          outputs a list of matching hosts; does not execute
                        anything else
  -m MODULE_NAME, --module-name=MODULE_NAME
                        module name to execute (default=command)
  -M MODULE_PATH, --module-path=MODULE_PATH
                        specify path(s) to module library
                        (default=/usr/share/ansible)
  -o, --one-line        condense output
  -P POLL_INTERVAL, --poll=POLL_INTERVAL
                        set the poll interval if using -B (default=15)
  --private-key=PRIVATE_KEY_FILE
                        use this file to authenticate the connection
  -S, --su              run operations with su
  -R SU_USER, --su-user=SU_USER
                        run operations with su as this user (default=root)
  -s, --sudo            run operations with sudo (nopasswd)
  -U SUDO_USER, --sudo-user=SUDO_USER
                        desired sudo user (default=root)
  -T TIMEOUT, --timeout=TIMEOUT
                        override the SSH timeout in seconds (default=10)
  -t TREE, --tree=TREE  log output to this directory
  -u REMOTE_USER, --user=REMOTE_USER
                        connect as this user (default=jw35)
  --vault-password-file=VAULT_PASSWORD_FILE
                        vault password file
  -v, --verbose         verbose mode (-vvv for more, -vvvv to enable
                        connection debugging)
  --version             show program's version number and exit

ansible-playbook

Usage: ansible-playbook playbook.yml

Options:
  -k, --ask-pass        ask for SSH password
  --ask-su-pass         ask for su password
  -K, --ask-sudo-pass   ask for sudo password
  --ask-vault-pass      ask for vault password
  -C, --check           don't make any changes; instead, try to predict some
                        of the changes that may occur
  -c CONNECTION, --connection=CONNECTION
                        connection type to use (default=smart)
  -D, --diff            when changing (small) files and templates, show the
                        differences in those files; works great with --check
  -e EXTRA_VARS, --extra-vars=EXTRA_VARS
                        set additional variables as key=value or YAML/JSON
  -f FORKS, --forks=FORKS
                        specify number of parallel processes to use
                        (default=5)
  -h, --help            show this help message and exit
  -i INVENTORY, --inventory-file=INVENTORY
                        specify inventory host file
                        (default=/etc/ansible/hosts)
  -l SUBSET, --limit=SUBSET
                        further limit selected hosts to an additional pattern
  --list-hosts          outputs a list of matching hosts; does not execute
                        anything else
  --list-tasks          list all tasks that would be executed
  -M MODULE_PATH, --module-path=MODULE_PATH
                        specify path(s) to module library
                        (default=/usr/share/ansible)
  --private-key=PRIVATE_KEY_FILE
                        use this file to authenticate the connection
  --skip-tags=SKIP_TAGS
                        only run plays and tasks whose tags do not match these
                        values
  --start-at-task=START_AT
                        start the playbook at the task matching this name
  --step                one-step-at-a-time: confirm each task before running
  -S, --su              run operations with su
  -R SU_USER, --su-user=SU_USER
                        run operations with su as this user (default=root)
  -s, --sudo            run operations with sudo (nopasswd)
  -U SUDO_USER, --sudo-user=SUDO_USER
                        desired sudo user (default=root)
  --syntax-check        perform a syntax check on the playbook, but do not
                        execute it
  -t TAGS, --tags=TAGS  only run plays and tasks tagged with these values
  -T TIMEOUT, --timeout=TIMEOUT
                        override the SSH timeout in seconds (default=10)
  -u REMOTE_USER, --user=REMOTE_USER
                        connect as this user (default=jw35)
  --vault-password-file=VAULT_PASSWORD_FILE
                        vault password file
  -v, --verbose         verbose mode (-vvv for more, -vvvv to enable
                        connection debugging)
  --version             show program's version number and exit

ansible-vault

playbooks_vault.html

Usage: ansible-vault [create|decrypt|edit|encrypt|rekey] [--help] [options] file_name

Options:
  -h, --help  show this help message and exit

See 'ansible-vault <command> --help' for more information on a specific command.

ansible-doc

Usage: ansible-doc [options] [module...]

Show Ansible module documentation

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -M MODULE_PATH, --module-path=MODULE_PATH
                             Ansible modules/ directory
  -l, --list            List available modules
  -s, --snippet         Show playbook snippet for specified module(s)
  -v                    Show version number and exit

ansible-galaxy

Usage: ansible-galaxy [init|info|install|list|remove] [--help] [options] ...

Options:
  -h, --help  show this help message and exit

  See 'ansible-galaxy <command> --help' for more information on a
  specific command 

ansible-pull

Usage: ansible-pull [options] [playbook.yml]

Introducing the NGINX Application Platform

We live in one of the most exciting times in history. The amount of technological innovation that has happened over the past few years is remarkable. For anyone looking to start their own business, the barriers to entry have never been lower. Existing organizations are more empowered than ever before to offer their services to a broad audience.At the core of this innovation is open source software. I’ve been fortunate to be involved in the open source world for many years. Open source has accomplished a great deal, but the best is definitely yet to come.Today I’m excited to announce the NGINX Application Platform. A suite of four products, built on open source technology, that together, I believe, will help organizations offer more to a broader, truly global audience. Combined, these four tools are at the core of what organizations need to create applications with performance, reliability, security, and scale.
The NGINX Application Platform gives enterprises the tools they need to deliver applications with performance,  reliability, security, and scale
The NGINX Application Platform gives enterprises the tools they need to deliver applications with performance,
reliability, security, and scale

The NGINX Application Platform begins with NGINX Plus, which you’re already familiar with. It’s the commercial variant of our popular open source NGINX software. NGINX Plus is a combined web server, content cache, and load balancer. You use NGINX Plus at the edge of your application to provide these services and act as a shield for the applications behind it.The second product is the NGINX Web Application Firewall (WAF), which we released earlier this year. Built on the widely deployed open source security software, ModSecurity, the NGINX WAF provides protections against Layer 7 attacks (such as SQL injection), scanners, bots, and other bad actors. The NGINX WAF is a dynamic module that plugs into NGINX Plus.

Introducing NGINX Unit

The third piece of the NGINX Application Platform meets a long‑standing need for the NGINX community. Many of our users call NGINX a “Swiss Army® knife” because it can do so much. No other software, commercial or open source, can do what NGINX does. Looking at the functionality of NGINX, though, there is one missing piece: it can’t run your application code directly.With NGINX Unit, we’re filling in that missing piece. NGINX Unit is a new application server designed by Igor Sysoev and implemented by the core NGINX software development team. Just like NGINX, Unit is open source. And Unit goes through the same rigorous development and testing practices as NGINX – so you’ll be able to deploy it with confidence.

With NGINX Unit you can run multiple languages and versions on the same server
With NGINX Unit you can run multiple languages and versions on the same server

What makes Unit unique is that it’s completely dynamic. You can switch to a new application version seamlessly, without restarting any processes. You can even have blue/green deployments within Unit and switch between them with no service disruption. All updates in Unit are graceful, with no restarting. And, all Unit configuration is handled through a built-in REST API using JSON configuration syntax; there’s no configuration file.Unit supports multiple languages. At launch, Unit will run code written in recent versions of PHP, Python, and Go. You can use Unit to run your WordPress sites. With Unit, you can run applications written in all these languages and language versions on the same server. We’ll be adding support for more languages, with Java and Node.JS support coming soon.We encourage you to give Unit a try and let us know what you think.

Introducing NGINX Controller

For as long as I’ve been at NGINX, we’ve envisioned creating a product that enables a single point of control for deploying, managing, and monitoring NGINX. That would take away the burden of managing the day‑to‑day of an application so you never get the pager call in the middle of night. Today I’m pleased to announce that product to you, the fourth and final piece of the NGINX Application Platform: NGINX Controller.NGINX Controller is a centralized monitoring and management platform for NGINX Plus. With Controller, you can manage hundreds of NGINX Plus servers from a single location. Using an intuitive graphical user interface you can create new instances of NGINX Plus and centrally configure features like load balancing, URL routing, and SSL termination. Controller has rich monitoring capabilities to help you monitor application health and performance. NGINX Controller is easy – even fun – to use.

Monitor and manage NGINX Plus with NGINX Controller
NGINX Controller makes it easier to monitor and manage large NGINX Plus deployments.

NGINX Controller helps enterprises move beyond the manual processes that stifle innovation. With NGINX Controller, IT provisions virtual load balancers for application teams, and then allows them to manage the load balancers themselves. This self‑service capability enables application teams to adopt agile development practice, while freeing IT to focus on maintaining a stable infrastructure, without disruptions.We have a strong vision and roadmap for NGINX Controller. Right now, NGINX Controller manages only NGINX Plus, but we’re working to expand that support to include NGINX WAF and NGINX Unit.NGINX Controller will be released as a private beta in Q4 2017, with full general availability scheduled for early next year. If you’d like to get on the list for the private beta, please sign up here.

Summary

Imagine a platform that’s based on one of the most important, and most widely respected, open source projects in the world. A platform that helps you develop and deliver fully modern apps – and that helps you extend existing application code strongly into the future. A platform that’s powerful, flexible, and extensible. And that makes application delivery easier, more effective, and even fun.The NGINX Application Platform gives enterprise a modern toolset for delivering complex applications. It is a suite of four products – NGINX Plus, NGINX WAF, NGINX Unit, and NGINX Controller – that together give enterprises the tools they need to build scalable and reliable applications.