Oleg Bukatchuk olegbukatchuk

Bucket Policy

Bucket policy is an access policy available for you to grant anonymous permissions to your Minio resources. Bucket policy uses JSON-based access policy language.

This section presents a few examples of typical use cases for bucket policies. The policies use testbucket strings in the resource value. To test these policies, you need to replace these strings with your bucket name. For more information please read Amazon S3 access policy language

Granting Read-Only Permission to an Anonymous User

The following example policy grants the s3:GetObject permission to any public anonymous users. This permission allows anyone to read the object data under testbucket, which is useful for when you have publicly readable assets. A typical example is a website assets stored in testbucket.

Moved to git repository: https://github.com/denji/nginx-tuning

NGINX Tuning For Best Performance

For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.

Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.

You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.

Network Setup

I have configured my network as following:

IP Address	Purpose
192.168.0.50	XenServer Host
192.168.0.51	Xen Orchestra
192.168.0.52/199	various VM's

Материалы по Go (golang)

На русском языке

Мануалы и туториалы

[Введение в программирование на Go][1]
[Маленькая книга о Go][3]
[Эффективный Go][2]
Есть еще [Краткий пересказ Effective Go на русском языке][4], но 2009 года

#Ambari API - Run all Service Checks In order to check the status and stability of your cluster it makes sense to run the service checks that are included in Ambari. Usually each Ambari Service provides its own service check, but their might be services that wont include any service check at all. To run a service check you have to select the service (e.g. HDFS) in Ambari and click "Run Service Check" in the "Actions" dropdown menu.

Service Checks can be started via the Ambari API and it is also possible to start all available service checks with a single API command. To bulk run these checks it is necessary to use the same API/method that is used to trigger a rolling restart of Datanodes (request_schedules). The "request_schedules" API starts all defined commands in the specified order, its even possible to specify a pause between the commands.

Available Service Checks:

Service Name	service_name	Command
HDFS	HDFS	HDFS_SERVICE_CHECK

	# System-wide .bashrc file for interactive bash(1) shells.
	if [ -z "$PS1" ]; then
	return
	fi

	git_branch() {
	git branch 2>/dev/null \| grep '^*' \| colrm 1 2
	}

	shopt -s checkwinsize

	#!/bin/sh
	set -eux

	VERSION=7.58.0
	OUTPUT=/opt/build

	rm -rf ${OUTPUT}
	mkdir ${OUTPUT}

	yum install -y openssl-devel gcc bzip2 make

	#!/bin/bash
	apt-get -y update

	apt-get -y install nano mc htop curl

	curl -fsSL get.docker.com -o get-docker.sh \
	&& chmod +x get-docker.sh \
	&& ./get-docker.sh

	curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose \

	#!/bin/bash

	# Usage: ./init.sh once to initialize remote storage for this environment.
	# Subsequent tf actions in this environment don't require re-initialization,
	# unless you have completely cleared your .terraform cache.
	#
	# terraform plan -var-file=./production.tfvars
	# terraform apply -var-file=./production.tfvars

	tf_env="production"

	#!/usr/bin/env bash
	TIME=60

	# Workload 70% read 30% write
	cat > fio-rand.fio << EOL
	[global]
	name=fio-rand-RW
	filename=fio-rand-RW
	rw=randrw
	rwmixread=70