DOCSLIB.ORG

Openshift Container Platform 3.11 Using Images

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Openshift Container Platform 3.11 Using Images OpenShift Container Platform 3.11 Using Images OpenShift Container Platform 3.11 Guide to Using Images Last Updated: 2021-07-14 OpenShift Container Platform 3.11 Using Images OpenShift Container Platform 3.11 Guide to Using Images Legal Notice Copyright © 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners. Abstract Use these topics to find out what different S2I (Source-to-Image), database and Docker images are available for OpenShift Container Platform 3.11 users. Table of Contents Table of Contents .C . H. .A . P. .T .E . R. 1.. .O . .V . E. .R .V . I. E. W. 6. .C . H. .A . P. .T .E . R. 2. S. .O . .U . R. C. E. -. T. .O . -. I. M. .A . G. E. ( .S . 2. I. ). 7. 2.1. OVERVIEW 7 2.2. JAVA 7 2.2.1. Overview 7 2.2.2. Versions 7 2.2.3. Images 7 2.2.4. Build Process 7 2.2.5. Configuration 8 2.2.6. Building and Deploying Java Applications 8 2.2.7. Building and Deploying from Source 9 2.2.8. Building and Deploying from Binary Artifacts 9 2.2.9. Java Environment Variables 9 2.2.10. Additional resources 20 2.3. .NET CORE 20 2.3.1. Benefits of Using .NET Core 20 2.3.2. Supported Versions 20 2.3.3. Images 20 2.3.4. Build Process 21 2.3.5. Environment Variables 21 2.3.6. Quickly Deploying Applications from .NET Core Source 23 2.4. NODE.JS 23 2.4.1. Overview 23 2.4.2. Versions 24 2.4.3. Images 24 2.4.4. Build Process 24 2.4.5. Configuration 24 2.4.6. Hot Deploying 25 2.5. PERL 26 2.5.1. Overview 26 2.5.2. Versions 26 2.5.3. Images 26 2.5.4. Build Process 26 2.5.5. Configuration 27 2.5.6. Accessing Logs 27 2.5.7. Hot Deploying 27 2.6. PHP 28 2.6.1. Overview 28 2.6.2. Versions 28 2.6.3. Images 28 2.6.4. Build Process 29 2.6.5. Configuration 29 2.6.5.1. Apache Configuration 31 2.6.6. Accessing Logs 31 2.6.7. Hot Deploying 31 2.7. PYTHON 32 2.7.1. Overview 32 2.7.2. Versions 32 2.7.3. Images 32 2.7.4. Build Process 32 1 OpenShift Container Platform 3.11 Using Images 2.7.5. Configuration 33 2.7.6. Hot Deploying 34 2.8. RUBY 34 2.8.1. Overview 34 2.8.2. Versions 34 2.8.3. Images 35 2.8.4. Build Process 35 2.8.5. Configuration 35 2.8.6. Hot Deploying 37 2.9. CUSTOMIZING S2I IMAGES 37 2.9.1. Overview 37 2.9.2. Invoking Scripts Embedded in an Image 38 .C . H. .A . P. .T .E . R. 3. D. A. .T .A . B. .A . S. .E . .I M. A. .G . E. .S . .4 .0 . 3.1. OVERVIEW 40 3.2. MYSQL 40 3.2.1. Overview 40 3.2.2. Versions 40 3.2.3. Images 40 3.2.4. Configuration and Usage 41 3.2.4.1. Initializing the Database 41 3.2.4.2. Running MySQL Commands in Containers 41 3.2.4.3. Environment Variables 41 3.2.4.4. Volume Mount Points 44 3.2.4.5. Changing Passwords 44 3.2.5. Creating a Database Service from a Template 45 3.2.6. Using MySQL Replication 46 3.2.6.1. Creating the Deployment Configuration for the MySQL Master 46 3.2.6.2. Creating a Headless Service 49 3.2.6.3. Scaling the MySQL Slaves 49 3.2.7. Troubleshooting 49 3.2.7.1. Linux Native AIO Failure 50 3.3. POSTGRESQL 50 3.3.1. Overview 50 3.3.2. Versions 51 3.3.3. Images 51 3.3.4. Configuration and Usage 51 3.3.4.1. Initializing the Database 51 3.3.4.2. Running PostgreSQL Commands in Containers 51 3.3.4.3. Environment Variables 52 3.3.4.4. Volume Mount Points 53 3.3.4.5. Changing Passwords 53 3.3.5. Creating a Database Service from a Template 55 3.4. MONGODB 55 3.4.1. Overview 55 3.4.2. Versions 55 3.4.3. Images 55 3.4.4. Configuration and usage 56 3.4.4.1. Initializing the database 56 3.4.4.2. Running MongoDB commands in containers 56 3.4.4.3. Environment Variables 57 3.4.4.4. Volume mount points 58 3.4.4.5. Changing passwords 58 2 Table of Contents 3.4.5. Creating a database service from a template 59 3.4.6. MongoDB replication 60 3.4.6.1. Limitations 61 3.4.6.2. Using the example template 61 3.4.6.3. Scale up 62 3.4.6.4. Scale down 62 3.5. MARIADB 63 3.5.1. Overview 63 3.5.2. Versions 63 3.5.3. Images 63 3.5.4. Configuration and Usage 64 3.5.4.1. Initializing the Database 64 3.5.4.2. Running MariaDB Commands in Containers 64 3.5.4.3. Environment Variables 65 3.5.4.4. Volume Mount Points 67 3.5.4.5. Changing Passwords 67 3.5.5. Creating a Database Service from a Template 68 3.5.6. Troubleshooting 69 3.5.6.1. Linux Native AIO Failure 69 .C . H. .A . P. .T .E . R. 4. .O . T. .H . E. .R . .I M. A. .G . E. .S . 7. .1 . 4.1. OVERVIEW 71 4.2. JENKINS 71 4.2.1. Overview 71 4.2.2. Images 71 4.2.3. Configuration and Customization 71 4.2.3.1. Authentication 71 4.2.3.1.1. OpenShift Container Platform OAuth authentication 72 4.2.3.1.2. Jenkins Standard Authentication 72 4.2.3.2. Environment Variables 73 4.2.3.3. Cross Project Access 75 4.2.3.4. Volume Mount Points 75 4.2.3.5. Customizing the Jenkins Image through Source-To-Image 75 4.2.3.6. Configuring the Jenkins Kubernetes Plug-in 77 4.2.3.6.1. Permission Considerations 79 4.2.4. Usage 79 4.2.4.1. Creating a Jenkins Service from a Template 79 4.2.4.2. Using the Jenkins Kubernetes Plug-in 80 4.2.4.3. Memory Requirements 82 4.2.5. Jenkins Plug-ins 82 4.2.5.1. OpenShift Container Platform Client Plug-in 82 4.2.5.2. OpenShift Container Platform Pipeline Plug-in 83 4.2.5.3. OpenShift Container Platform Sync Plug-in 83 4.2.5.4. Kubernetes Plug-in 84 4.3. JENKINS AGENTS 84 4.3.1. Overview 84 4.3.2. Images 84 4.3.3. Configuration and Customization 85 4.3.3.1. Environment Variables 85 4.3.4. Usage 86 4.3.4.1. Memory Requirements 86 4.3.4.1.1. Gradle builds 86 4.3.5. Agent Pod Retention 87 3 OpenShift Container Platform 3.11 Using Images 4.4. OTHER CONTAINER IMAGES 88 4 Table of Contents 5 OpenShift Container Platform 3.11 Using Images CHAPTER 1. OVERVIEW Use these topics to discover the different Source-to-Image (S2I), database, and other container images that are available for OpenShift Container Platform users. Red Hat’s official container images are provided in the Red Hat Registry at registry.redhat.io. OpenShift Container Platform’s supported S2I, database, and Jenkins images are provided in the openshift3 repository in the Red Hat Registry. For example, registry.redhat.io/openshift3/ose for the Atomic OpenShift Application Platform image. The xPaaS middleware images are provided in their respective product repositories on the Red Hat Registry, but suffixed with a -openshift. For example, registry.redhat.io/jboss-eap-6/eap64-openshift for the JBoss EAP image.
Load more

Recommended publications
  • Load Testing of Containerised Web Services
    UPTEC IT 16003 Examensarbete 30 hp Mars 2016 Load Testing of Containerised Web Services Christoffer Hamberg Abstract Load Testing of Containerised Web Services Christoffer Hamberg Teknisk- naturvetenskaplig fakultet UTH-enheten Load testing web services requires a great deal of environment configuration and setup. Besöksadress: This is especially apparent in an environment Ångströmlaboratoriet Lägerhyddsvägen 1 where virtualisation by containerisation is Hus 4, Plan 0 used with many moving and volatile parts. However, containerisation tools like Docker Postadress: offer several properties, such as; application Box 536 751 21 Uppsala image creation and distribution, network interconnectivity and application isolation that Telefon: could be used to support the load testing 018 – 471 30 03 process. Telefax: 018 – 471 30 00 In this thesis, a tool named Bencher, which goal is to aid the process of load testing Hemsida: containerised (with Docker) HTTP services, is http://www.teknat.uu.se/student designed and implemented. To reach its goal Bencher automates some of the tedious steps of load testing, including connecting and scaling containers, collecting system metrics and load testing results to name a few. Bencher’s usability is verified by testing a number of hypotheses formed around different architecture characteristics of web servers in the programming language Ruby. With a minimal environment setup cost and a rapid test iteration process, Bencher proved its usability by being successfully used to verify the hypotheses in this thesis. However, there is still need for future work and improvements, including for example functionality for measuring network bandwidth and latency, that could be added to enhance process even further. To conclude, Bencher fulfilled its goal and scope that were set for it in this thesis.
    [Show full text]
  • Abkürzungs-Liste ABKLEX
    Abkürzungs-Liste ABKLEX (Informatik, Telekommunikation) W. Alex 1. Juli 2021 Karlsruhe Copyright W. Alex, Karlsruhe, 1994 – 2018. Die Liste darf unentgeltlich benutzt und weitergegeben werden. The list may be used or copied free of any charge. Original Point of Distribution: http://www.abklex.de/abklex/ An authorized Czechian version is published on: http://www.sochorek.cz/archiv/slovniky/abklex.htm Author’s Email address: [email protected] 2 Kapitel 1 Abkürzungen Gehen wir von 30 Zeichen aus, aus denen Abkürzungen gebildet werden, und nehmen wir eine größte Länge von 5 Zeichen an, so lassen sich 25.137.930 verschiedene Abkür- zungen bilden (Kombinationen mit Wiederholung und Berücksichtigung der Reihenfol- ge). Es folgt eine Auswahl von rund 16000 Abkürzungen aus den Bereichen Informatik und Telekommunikation. Die Abkürzungen werden hier durchgehend groß geschrieben, Akzente, Bindestriche und dergleichen wurden weggelassen. Einige Abkürzungen sind geschützte Namen; diese sind nicht gekennzeichnet. Die Liste beschreibt nur den Ge- brauch, sie legt nicht eine Definition fest. 100GE 100 GBit/s Ethernet 16CIF 16 times Common Intermediate Format (Picture Format) 16QAM 16-state Quadrature Amplitude Modulation 1GFC 1 Gigabaud Fiber Channel (2, 4, 8, 10, 20GFC) 1GL 1st Generation Language (Maschinencode) 1TBS One True Brace Style (C) 1TR6 (ISDN-Protokoll D-Kanal, national) 247 24/7: 24 hours per day, 7 days per week 2D 2-dimensional 2FA Zwei-Faktor-Authentifizierung 2GL 2nd Generation Language (Assembler) 2L8 Too Late (Slang) 2MS Strukturierte
    [Show full text]
  • Alchemist: Fusing Application and Audit Logs for Precise Attack Provenance Without Instrumentation
    ALchemist: Fusing Application and Audit Logs for Precise Attack Provenance without Instrumentation Le Yu∗, Shiqing May, Zhuo Zhang∗, Guanhong Tao∗, Xiangyu Zhang∗, Dongyan Xu∗, Vincent E. Uriasz, Han Wei Linz, Gabriela Ciocarliex, Vinod Yegneswaranx and Ashish Gehanix ∗Purdue University; yRutgers University; zSandia National Laboratories; xSRI International ∗fyu759, zhan3299, taog, xyzhang, [email protected], [email protected], zfveuria, [email protected], xfgabriela, vinod, [email protected] Abstract—Cyber-attacks are becoming more persistent and processes into execution units/tasks [53], [45]. Each unit/task complex. Most state-of-the-art attack forensics techniques either is an autonomous portion of the whole execution such as a tab require annotating and instrumenting software applications or in firefox. An output operation is considered dependent on all rely on high quality execution profiling to serve as the basis the preceding input operations within the same unit. Doing so, for anomaly detection. We propose a novel attack forensics they can preclude a lot of false dependencies. Researchers have technique ALchemist. It is based on the observations that built- demonstrated the effectiveness of these unit partitioning based in application logs provide critical high-level semantics and audit logs provide low-level fine-grained information; and the two share techniques, which yield very few dependence false positives a lot of common elements. ALchemist is hence a log fusion and false negatives [53], [45]. However, these approaches re- technique that couples application logs and audit logs to derive quire third-party instrumentation, which may not be acceptable critical attack information invisible in either log. It is based on a in enterprise environments.
    [Show full text]
  • Secure by Default-The Case Of
    Secure by default – the case of TLS Martin Stanek Department of Computer Science Comenius University [email protected] Abstract Default configuration of various software applications often neglects security objectives. We tested the default configuration of TLS in dozen web and application servers. The results show that “secure by default” principle should be adopted more broadly by developers and package maintain- ers. In addition, system administrators cannot rely blindly on default security options. Keywords: TLS, secure defaults, testing. 1 Introduction Security often depends on prudent configuration of software components used in a deployed system. All necessary security controls and options are there, but one have to turn them on or simply start using them. Unfortunately, the “If it ain’t broke, don’t fix it” philosophy or a lack of expertise wins sometimes. The technology is deployed in a default configuration or configuration that fulfills (mostly functional) requirements with as few changes as possible. Secure by default is a well known security principle, see e.g. [4]: Technology which is Secure by Default has the best security it can without you even knowing it’s there, or having to turn it on. We should aim to provide software packages with safe defaults and turning them to less secure config- uration should require a deliberate effort, see e.g. [5]: There are many ways to deliver an “out of the box” experience for users. However, by default, the experience should be secure, and it should be up to the user to reduce their security – if they are allowed. arXiv:1708.07569v1 [cs.CR] 24 Aug 2017 The Transport Layer Security (TLS) and its predecessor Secure Socket Layer (SSL) are widely used protocols for ensuring confidentiality and integrity of transported data, as well as one or two-sided authentication of communicating parties.
    [Show full text]
  • Linh Chau Enterprise Software Architect
    Linh Chau Enterprise Software Architect/Senior Software Engineer Current Location: Austin, TX Email: [email protected] Personal public code repository: https://bitbucket.org/linhchauatl/ PROFESSIONAL QUALIFICATIONS • Twenty three years working experience as Software Developer (three years in Asia, two years in Germany and eighteen years in the United States). • Eighteen years experience of team work and leadership with local and distributed groups in Germany, United States, Japan, France, China, etc. • Eighteen years of intensive experience in configuration management, source code control, version configuration. • Twenty one years experience of Software development using OO methodologies, OOA, OOD, Design Patterns, UML visual design with Rational Rose, Agile, XP. • Good communication skills, both written and verbal. • Sixteen years experience with Enterprise Production Systems (PDM, PLM, CRM, and ERP) written in Java and Ruby. SKILLS: Operating Systems Mac OS X, iOS, Linux (RedHat, CentOS, Ubuntu, Mint) Languages Ruby, C++, C, Java, Go, Elixir, Rust, javascript UI Technologies HTML, CSS, HAML, ERB, Slim, Ajax, jQuery, ReactJS Frameworks Rails, Sinatra Web servers & App Apache, Nginx, Unicorn, Puma, Passenger, Mongrel, lighttpd, Tomcat, servers JRun, WebLogic, WebSphere, JBoss Databases MySQL, PostgreSQL, MongoDB, Oracle, DynamoDB, SQL Server Methodology Agile, Scrum, BDD, TDD, RUP, XP (Extreme Programming), OOAD, Design Patterns Tools & Utilities Git, docker, AWS services (EC2, S3, ELB, RDS, DynamoDB, ASG, Route53, SQS, SNS …etc…),
    [Show full text]
  • Scalable Web Applications
    Scalable Web Applications Samuel Williams [email protected] www.codeotaku.com @ioquatix Scalable Web Applications Samuel Williams [email protected] www.codeotaku.com @ioquatix What if I told you, you can take your existing web application, and make it more efficient and scalable? “It’s not possible” you’d cry! Well… you are in for a surprise. Welcome to my talk “Scalable Web Applications”. My name is Samuel Williams and I’m a Ruby core team member. Today we are going to talk about scalability, and how Ruby 3 unlocks the next evolution of concurrency, to help you build scalable web applications. What is Scalability? スケーラビリティとは何か？ Firstly, let’s talk about scalability. From a software perspective, scalability is about how a system’s performance changes as the requirements on the system grow. A simple example would be, does your system get slower as the number of users increases? There are lots of different ways to talk about scalability, but let us consider four key questions. Can I add capacity to handle increased demand? 増加する要求に対応できる容量を追加できるのか？ Can I add capacity to handle increased demand? This is perhaps the biggest problem when building scalable web applications. While trivial applications can be easy to scale up, once you start depending on external services, such as databases, key-value stores, software-as-a-service, it can be hard to know which parts of your system are causing performance issues and how to mitigate them. Contention コンテンション（競合） In many cases, limited or metered resources are something that need to be carefully monitored as they can cause contention.
    [Show full text]
  • 1St Edition Contents
    1st edition Contents 1 Introduction 14 1.1 Acknowledgment ......................... 15 1.2 Expectations ............................ 16 1.3 Conventions ............................ 17 1.4 Feedback .............................. 18 2 Bird’s Eye 19 2.1 High-Level Concepts ....................... 20 3 Operating Systems 23 3.1 Fedora and Friends ........................ 24 3.2 Terminals and Shells ....................... 26 3.2.1 Commands ........................ 26 3.2.2 Standard Streams ..................... 30 3.2.3 File Editing ........................ 34 3.2.4 Navigation ........................ 35 3.2.5 Pipelines .......................... 37 3.3 Summary .............................. 39 2 4 Little Bit of Network Theory 40 4.1 Mental Model ........................... 41 4.1.1 Signals and Waves .................... 42 4.1.2 Internet .......................... 44 4.1.3 Transport ......................... 50 4.1.4 Applications ........................ 52 4.2 Summary .............................. 55 5 Secure Connections 56 5.1 SSH and OpenSSH ........................ 57 5.1.1 SSH Keys ......................... 58 5.2 A First Server ........................... 60 5.3 Remote Shell ............................ 62 5.4 File Transfers ........................... 64 5.5 SSH on Servers .......................... 65 5.6 SSH Tunneling ........................... 69 5.7 Summary .............................. 71 6 Hands-On Networking 72 6.1 Network Interfaces ........................ 73 6.2 MAC and IP Addresses ...................... 75 6.3 Sending
    [Show full text]
  • A Software Approach to Defeating Side Channels in Last-Level Caches
    A Software Approach to Defeating Side Channels in Last-Level Caches Ziqiao Zhou Michael K. Reiter Yinqian Zhang University of North Carolina University of North Carolina Ohio State University Chapel Hill, NC, USA Chapel Hill, NC, USA Columbus, OH, USA ABSTRACT do not require preemption of the victim to extract fine- grained information from it (e.g., [35, 37, 12, 21]). We present a software approach to mitigate access-driven Two varieties of LLC-based side channels capable of side-channel attacks that leverage last-level caches extracting fine-grained information from a victim have (LLCs) shared across cores to leak information between been demonstrated. The first such attacks were of the security domains (e.g., tenants in a cloud). Our approach FLUSH-RELOAD variety [35, 37], which requires the at- dynamically manages physical memory pages shared be- tacker to share a physicalmemory pagewith the victim— tween security domains to disable sharing of LLC lines, a common situation in a modern OS, due to shared li- thus preventing “FLUSH-RELOAD” side channels via brary, copy-on-write memory management and memory LLCs. It also manages cacheability of memory pages deduplication mechanisms that aim for smaller mem- to thwart cross-tenant “PRIME-PROBE” attacks in LLCs. ory footprints. The attacker first FLUSHes a cache-line We have implemented our approach as a memory man- sized chunk of the shared page out of the cache using agement subsystem called CACHEBAR within the Linux processor-specific instructions (e.g., clflush in x86 kernel to intervene on such side channels across con- processors) and later measures the time to RELOAD (or tainer boundaries, as containers are a common method re-FLUSH [8]) it to infer whether this chunk was touched for enforcing tenant isolation in Platform-as-a-Service (and thus loaded to the shared cache already) by the (PaaS) clouds.
    [Show full text]
  • Radislav Golubtsov
    Radislav Golubtsov OBJECTIVE To obtain the position of a Software Developer / Senior Software Developer An IT multilinguist SUMMARY Total IT experience – 20 years Hardware ● Intel x86 (i686 / x86-64) ● HP PA-RISC ● IBM PowerPC ● Sun SPARCstation Operating Unices and derivatives (OpenBSD, FreeBSD, Arch Linux, Debian GNU/Linux, Systems Ubuntu, Fedora, CentOS, Red Hat Enterprise Linux, Mac OS X, HP-UX, IBM AIX, Sun Solaris). Microsoft Windows Programming C, Go, Java, Perl 5, Python 2/3, Bash Shell Script, JavaScript (ES5-6/Node.js), Languages GNOME Vala/Genie, Lua, C++, Objective-C 2.0, Fortran 95, Erlang, Elixir, LFE (Lisp Flavoured Erlang), Clojure Technologies ● Python and related modules, libraries, and frameworks (Python Standard Library, Twisted Web, Klein, Falcon, Flask, Celery, Django REST framework, ReportLab PDF Toolkit, etc.) ● Linux kernel API, Linux kernel modules (block device driver) ● Perl and related modules, libraries, and frameworks (DBI, CGI, LWP, Mojolicious, Text::Xslate, Asterisk::AGI, Net::DNS::Native, IO::Select, etc.) ● IVR (Interactive Voice Response) using Asterisk VoIP PBX ● GNU libmicrohttpd (C library to make a lightweight multi-threaded HTTP server), GNU C Library (glibc), GNU C++ Library (libstdc++), GNOME libsoup ● GTFS Realtime (General Transit Feed Specification), Google Text-To-Speech API ● Java SE / EE, Java Servlet, JavaServer Pages (JSP), JSP Standard Tag Library (JSTL), Java Portlet, Spring Boot, Spring Web MVC, Spring Security, Play! Framework, Vaadin Framework, Apache Struts / Struts 2, JavaServer Faces (JSF), Java Database Connectivity (JDBC), JavaMail, Java Abstract Window Toolkit (AWT), Java Swing, iText (Java-PDF Library), jQuery (JavaScript Library), Node.js / Luvit, Harpjs.com, HTML, CSS, XML, YAML, JSON, SQL, GNUstep / Cocoa API, Eclipse Standard Widget Toolkit (SWT), HTTP(S), (S)FTP, SSH, SCP, RESTful microservices, etc.
    [Show full text]
  • Open Source Software Options for Government
    Open Source Software Options for Government Version 2.0, April 2012 Aim 1. This document presents options for Open Source Software for use in Government. 2. It is presented in recognition that open source software is underused across Government and the wider public sector. 3. This set of options is primarily intended to be used by Government to encourage IT suppliers and integrators to evaluate open source options when designing solutions and services. 4. This publication does not imply preference for any vendor or product. Open source software, by definition, is not tied inextricably to any particular commercial organisation. Any commercial entity can choose to support, maintain, or integrate open source software. 5. It is understood that the software market, and the open source ecosystem in particular, is a rapidly developing environment and any options list will be incomplete and may become outdated quickly. Even so, given the relatively low level of open source experience in Government, this options list has proven useful for encouraging IT suppliers to consider open source, and to aid the assurance of their proposals. Context 1. The Coalition Government believes Open Source Software can potentially deliver significant short and long term cost savings across Government IT. 2. Typical benefits of open source software include lower procurement prices, no license costs, interoperability, easier integration and customisation, fewer barriers to reuse, conformance to open technology and data standards giving autonomy over your own information, and freedom from vendor lock in. 3. Open Source is not widely used in Government IT. The leading systems integrators and supplies to Government do not routinely and effectively consider open source software for IT solutions, as required by the existing HMG ICT policy.
    [Show full text]
  • Openshift Container Platform 3.9 Using Images
    OpenShift Container Platform 3.9 Using Images OpenShift Container Platform 3.9 Guide to Using Images Last Updated: 2019-07-06 OpenShift Container Platform 3.9 Using Images OpenShift Container Platform 3.9 Guide to Using Images Legal Notice Copyright © 2019 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
    [Show full text]
  • Managing Ruby on Rails Applications (Code: Rails Admin)
    Managing Ruby on Rails Applications (code: Rails Admin) Overview Ask for details Phone +44 203 608 6289 Ruby programming language was created by Yukihiro Matsumoto (Matz) and [email protected] firstly published in 1995. It’s a very modern, interpreted programming language available on many platforms. It’s pure, object-oriented language which adopted many of its properties from the Smalltalk language. Ruby on Rails is advanced environment (framework) which allows us to create modren and advanced services / web applications (websites) in a quick, non-stressful way. During the intensive, two days course participants will understand pros and cons of different methods regarding configuration and maintaining production, staging and development environments of Ruby on Rails. We will discuss methods of fast implementing new applications version, optimizing environment for better performance, diagnosing errors and avoiding failures. We will also discuss some aspects of security of Ruby on Rails application (and web applications in general). The course is intended for systems administrators, who want to get familiar with managing Ruby on Rails applications, as well as programmers, who plan to manage and maintain their applications in production environment. Duration 2 days Agenda 1. Basic definitions — The most important performance requirements in Ruby on Rails — Review of HTTP basics — Ruby language in a nutshell — Main concepts and technologies related to web applications — Characteristics of Ruby on Rails environment 2. Environment of application in Ruby language — Basic methods of installing the language — Virtual environments of installing language (rvm, rbenv, ruby-install, chruby) — Gems and Bundlers — Ruby gems binary dependencies — Configuring time zone and language settings (locale) 3.
    [Show full text]